• Topic Archived
You're browsing the GameFAQs Message Boards as a guest. Sign Up for free (or Log In if you already have an account) to be able to post messages, change how messages are displayed, and view media in posts.

User Info: ReconditePhreak

2 years ago#141
good luck on the test :)

I'm sorry for the delay guys, things keep grabbing my attention, I'm hoping to get more time this coming weekend.
Believes the individuals who report to moderators wish they had more control than they do.

User Info: Cheezmeister

2 years ago#142
Sinroth posted...
I'm counting down the hours until I kick the ass of this analysis test

I make games!

User Info: ReconditePhreak

2 years ago#143
alright, we're live and executing stuff ... just not a lot of stuff (yet!) :)

The idea is you compile/run and then run a diff on the files 'resources/nestest.out' and 'resources/nestest.log'. That should show you immediately what differs. identify/fix the issue, recompile/rerun, check the diff again... ad nauseum.

trustiness itself is setup to panic in 2 places.

1. the logger will panic if it comes across an addressing mode it doesn't know how to log, and
2. the cpu executor will panic if it comes across an opcode it doesn't have implemented yet.

In my opinion it's best to only implement them when first encountered and the logs show all previous opcodes/addressing modes are implemented properly.

I think the output log should mostly be self explanatory, but just in case

(1) C000 (2) 4C F5 C5 (3) JMP (4) $C5F5 A:00 X:00 Y:00 (5) P:24 (6) SP:FD

(1) is the pc in hex
(2) are the bytes of the instruction. The first byte is always the opcode itself (0x4C represents the JMP opcode). This is variable length, this particular instruction has an Absolute Addressing mode which means the next 2 bytes represent a 16 bit address.

(3) and (4) are basically the same as (2) only human readable. Note that (2) is F5 C5 and (4) has $C5F5 (opposite order). In this case (4) is how you would enter it into 6502 assembly and the linker would swap the bytes for you.

(5) are the cpu status flags packed into an int (carry, overflow, etc) and represented in hex

(6) is the stack pointer.


Currently if you run and diff you'll see that the status flags (P:XX) are different, I'm going to have to investigate why, but this is a good opportunity for everyone to track down/test their diff program of choice. I personally use vimdiff and can confirm it works well.

That's it for now, if anyone has any questions or suggestions, please let me know.
Believes the individuals who report to moderators wish they had more control than they do.

User Info: ReconditePhreak

2 years ago#144
So rust is kind of dumb in surprising ways.


would fail because cpu_state was already bound (to the function call...). It's doubly stupid because cpu_state.a is intrinsically copyable.


Also didn't work, even though you're explicitly telling the compiler this is copyable.

THIS however... worked. Note the order of the parameters...

set_zs(cpu_state.a, cpu_state);

I didn't like that solution for 2 reasons.

1. it's the opposite of natural imo, and
2. you're specifying your parameters based upon an assumption of the variables used at the call site. wut?

I ended up using a macro


Arguably a macro is the right call here anyway since inlining these operations is probably a good idea, but it took me a bit to get there. In the interim I played around with using tuples. It turned into this.

match get_zs(cpu_state.a) {
(z,s) => { cpu_state.Z = z; cpu_state.S = s; }

When I started looking into tuples I thought you could destructure them naturally, like so:

(cpu_state.Z,cpu_state.S) = get_zs(cpu_state.a)

nope, you can only do that with new variable bindings (let statement).

The thing is, I get the restriction. If you're passing in a field of a struct that's non-copyable and the struct itself and both are passed, it's both silly and potentially dangerous. I get it.

but that isn't what I was doing, and I feel like it should be perfectly legal to do.

of course, arguably I should have put the function on cpu_state, like so


But that's beside the point.

rust is kind of dumb sometimes.
Believes the individuals who report to moderators wish they had more control than they do.

User Info: Sakum

2 years ago#145
ReconditePhreak posted...
rust is kind of dumb sometimes.

At least it's less dumb than R:

* Can't pass by reference (meaning a recursive procedure on a data frame will blow up the stack in very few iterations)

* Lists aren't real hashes (meaning I can't put anything I want as the key value. And the fact they are half-hashes in the first place is dumb, but it's for "named" indices).

* You have to painstakingly dig stuff out when using regex matches.

* TWO different array index notations, [] and [[]]. Ugly and silly.

* Indices start at 1 (not that bad actually, but still kinda dumb)

* The "de facto" assignment statement is three key-presses: <- . You can also assign in the other direction with -> . I feel like this was made by the creators in a weak attempt to make their language look cooler. '=' still does the same thing it does in other ALGOL-flavoured languages, with some sort of subtle difference.

* Loops are frowned upon for some stupid reason. Apparently R's compiler is so awful it can't really optimize them very well, so some people bend ass-backwards to use a function like sapply instead when a for-loop would've been way more readable. (NOTE: Some people are even encouraged to write C to optimize their code, when R is suppose to be a convenient language for non-programmers to do plotting and stats in).

That being said, it is pretty good at what it needs to do. Data transformation is not one of its highest points, but number crunching and plotting is pretty reasonable. Most people probably use Python for the lower level stuff, and then R to finish the job.

So there you go! At least you aren't using R for this thing. Which would be completely hilarious, as R is mostly for data analysis, but hey.
What's in the booox?!

User Info: Sinroth

2 years ago#146
One of the guys at one of my jobs is an R guy. His programs are barely readable mushes of -> and apply.

Was the R rant inspired by the Rust <-> R thing someone made?
I live in a big house and it's handy to have a pair of running shoes so that it doesn't take me forever to get from one area of the house to another.

User Info: Sakum

2 years ago#147
Sinroth posted...
One of the guys at one of my jobs is an R guy. His programs are barely readable mushes of -> and apply.

Was the R rant inspired by the Rust <-> R thing someone made?

That is hilarious. And sad. Although I feel like it is actually somewhat difficult to write a somewhat complex R program that doesn't look ugly, however, but not obsessing over the *apply functions helps.

Nah, there was something like that by someone on here? I brought it up because the main man here was bemoaning some Rust inadequacies. Just wanted to make him feel better. R is quite possibly the "worst" programming language I have ever written in. Even its creators (or at least one of them) thinks it is time for "something different" (Julia will come to the rescue, perhaps).

What a hilarious comparison. A multi-paradigm language compared to a statistical computing language that is like Perl's lost cousin? Hah! They both begin with the same letter though, I guess. I've been using Octave as of late (free, allegedly crippled MATLAB that is less efficient in some areas) and it is much less error-prone and much more consistent. R has lots of little rules that cause stupid bugs to occur when you least expect it. At least when I'm programming in my favourite 1-letter programming language (C) I can almost always realise what my error might've been, assuming I've been careful...
What's in the booox?!

User Info: ReconditePhreak

2 years ago#148
yeah, I actually kind of prefer C/C++ to rust. I'm still withholding final judgement, but rust seems to get in your way a lot.

My kvetching above is one example, but then there's other things as well.

The following won't compile.

let v = -1 as u8;

but the following will

let v = -1 as i8;
let x = v as u8;

I mean it's not *that* big of a deal, you can always do the following

let v = 0xFF as u8;

I really dislike their coercion rules, I mentioned this example earlier. The follow will unequivocally panic.

let v = std::u8::MAX+1;

because it doesn't coerce, v is a u8 and adding 1 to the max value is arithmetic overflow, which in rust... panic's.

instead you have to do the following

let v:u16 = std::u8::MAX+1;
let x = std::u8::MAX as u16 +1;

Probably the biggest grievance I've encountered so far is in our execute function.

Before we were doing the following.

let dr = &cpu_state.decode_register;

But the problem is that you can no longer pass the cpu_state object as mutable to other functions until that dr variable falls out of scope; Which was a problem because I wanted to create a few functions for setting the zero and sign bit, but that requires passing cpu_state as mutable... The s***ter of it is that static analysis could determine what I was doing was completely safe, but rust isn't good enough to do that yet.

This can be gotten around by writing a macro, but the functions aren't always going to be that simple.

Then there's the biggest travesty of them all. safe code around unsafe blocks are extremely unsafe.

This is because safe code can mutate state that unsafe code uses, thereby causing the unsafe code to crash and burn in a major way. In essence, if you have unsafe code in your module, then the entire module is tainted and everything in it should be treated as unsafe.

I would say don't EVER use outside state in an unsafe code block. If the user of your module passes in an argument that is either directly used by unsafe blocks, or affects state used by unsafe blocks, you may as well be writing C or C++.

I almost don't see the point of the safe/unsafe dichotomy, but I think it just hasn't been realized yet.

I think the value in the safe/unsafe dichotomy is going to be in the tooling around it. I think you'll have things tooling that can analyze the unsafe blocks and give you more information about the code around it. Imagine struct fields used by unsafe blocks that are given a pink background in your IDE so you can tell at a glance that you had damned well be extra super careful with how you mutate that field.

But in current rust, I'm of the opinion that unsafe blocks serve little to no purpose and don't actually protect you much better than C or C++. I think private module variables and private struct fields do more to protect you than safe/unsafe blocks (but I think that will change). The value in them currently is when the tooling does catch up, the code is already participating in the dichotomy.

And that isn't to say that I dislike rust, but I'm finding myself strongly disabused of a lot of notions I had going in based upon other people talking about it.
Believes the individuals who report to moderators wish they had more control than they do.

User Info: ReconditePhreak

2 years ago#149
but since I've been b****ing about rust...

I actually really like their error handling mechanisms, I think they're far and away superior to anything else I've experienced.

I like their macro system (what I've seen of it).

I like their module, and testing, system. I'm not convinced that putting tests next to the code (in the same module) is a good idea, but I'm still open to trying it out eventually. trustines was just never going to have that many tests and I didn't see the point.

In general I do like their ownership/lifetime system, although I think it needs to improve a lot. I like that things move by default (as opposed to C++ where a bit of work is often necessary for it).

I like rust, but there are aspects of it that aggravate me, and other aspects that I think aren't ever going to meet the goals people seem to attribute to them.
Believes the individuals who report to moderators wish they had more control than they do.

User Info: SeraphLance

2 years ago#150
This popped up on reddit today, which I think RP might be interested in:

Hello. My name is Inigo Montoya. You killed my father. Prepare to die.
  • Topic Archived