(11-10-2016, 10:04 PM)mzxrules Wrote: Seems like it was written for kids. Lets see if I can't find a few errors:
It's supposed to be for "beginners", therefore it is kept very rough in some parts without giving out too much detail, and once I had the idea of making some "tests" for my tutorial, but I knew that was pointless, so I never continued that path. If it is in your eyes written in the style of a kids' novel, so be it. However, most people seem to have been profiting from this revision more than from my older ones. So, I think this style is completely fine.
1. Yes, they are 64-bit wide. However, as far as I remember the registers were always used in 32-bit mode (at least in N64), not 64-bit mode, thus me purposefully leaving out the fact of the MIPS registers actually being 64-bit wide. Also, most N64 debuggers I know of only display GPU registers in a length of 32- bits. Still, I added this small detail of the registers actually being 64-bit wide.
2. There existed (at least on StackOverflow) a lot of confusion before whether 16-bit immediate values in ADDI and ADDIU are both signed or unsigned (as the latter instruction in its name does imply). In fact, both instructions are sign-extended, with the difference that ADDI throws an overflow exception while ADDIU does not. In that connection the question came up what would happen if the 16-bit immediate value in the ADDIU instruction exceeds 0x7FFF, where I wanted to clarify that in this case no overflow exception is given. Of course, I was wrong on the length though because I mistakenly was referring to the 16-bit immediate value and not the sum, from which (as you said correctly) the overflow exception would occur from, if it exceeds the max integer value in the register. Also, if I'm right the max value should (in the case of N64, running in 32-bit mode) in fact be 2^31-1 and not 2^63-1.
3. Typo, fixed.
4. Odd phrase, fixed to a more objective phrase. "rogue" should be "rough" or "superficial", fixed too.
5. I was kinda optimistic that people would get that themselves, which is why I didn't use it in an actual instruction but in the explanation in the instruction formats. Fixed it anyway.
6. That detail isn't really necessary for beginners though, which is why I roughly summarized it, and marked a hint with quoting "direct" because it actually isn't a direct addressing, more like pseudo-direct addressing as you pointed out. I still add it though in brackets, so "experts" (which I doubt most beginners will be, but whatever...) or curious people get more detail on this.
Thanks for counting up some minor mistakes.
I stopped working on that tutorial for a while and some errors listed by you were supposed to be clarified and fixed (I remember kaze telling me about them long ago) except for the typos (thanks btw), but when I lost interest in SM64 Hacking a while ago, I stopped continuing on this and just released it now in the state as it was before. Sorry 'bout that.
Possibly in the near future I might get enough time to completely rewrite this and walk a middle path (giving additional details (footnotes), but still focusing on the basics instead of just focusing on the basics and completely leaving out the details).
(11-10-2016, 10:04 PM)mzxrules Wrote: Unrelated, # for decimal? Invented a pseudo-opcode just for the parser? Why
Because it was my decision to do so. Originally, I planned to have decimal values have not any symbol (as this is the case for most assemblers), however I noticed that this didn't seem to work out very well, so I did leave it in the way it was since 1.0 release.
As no one (from the communities I know of that regularly use my assembler) complained about this so far, I don't see it as a big deal anyway and thus there's no need to do anything about it.
Thanks again, btw.