Some thoughts on instruction set

[binji]

Hi, just saw your twitter post and thought I'd take a look!

First off, this is very cool!

Some initial thoughts/comments:

• looks like a typo in the table, should say bits 10-13 I think?
• No unsigned integer div? Also wonder what happens on divide by zero.
• No remainder/modulo?
• Cool that int and float regs are the same set!
• fcmp might be weird with NaN, guess it depends on how you store comparison results.
• shift_right doesn't say if it's logical or arithmetic (assume arithmetic since other ops are signed?)
• Bit of a tradeoff, but I wonder if it would be nicer to have fixed size instructions. Makes disassembling much nicer, at the cost of having to be more clever when loading large immediates.
• No 16-bit loads/stores?
• Maybe multiply offset by load/store size? Maybe not a big deal here since you have 18-bits of offset though.
• Might be nice to have an instruction to allocate space on the stack for locals, as is I think you'd have to do something like mov <bytes>, rn; sub sp, rn, sp which uses an extra register.
• I think pop should work in opposite order of push; increase sp, then read.
• Any thoughts about interrupt handling? It makes everything more complicated, but without it things like timers are gonna be tricky.

[badlogic]

Thanks for the feedback!

• I guess unsigned int mul/div and modulomake sense. I initially had them, then removed them for simplicities sake.
• fcmp is one huge TBD :)
• shifts are bitwise and non-arithmetic.
• fixed size instructions would indeed be nice, but then i'd shoot myself in the food if the address space ever gets bigger than the currently assumed 16mb.
• i'll add 16-biy load/stores
• when working with different archs i always found consistent offsetting to be easier for my brain. i will keep it this way.
• i'll add an alloca equivalent, will be useful for other things as well
• sp always points at the last pushed value, so for pop i have to read, then subtract
• i added ports as a polling and blocking workaround. i think for most things this will be sufficient. i do jot rule out adding interrupts later though, as they are a nice segway into the topic of callbacks.

Thanks again, i'll update the specs as soon as i find a spare hour :)

[binji]

I think you get unsigned mul for free, since it's sign-agnostic as long as you assume 2's complement.

i added ports as a polling and blocking workaround. i think for most things this will be sufficient.

Ah, I didn't notice that port_read is blocking. OK, seems like it could work :-)

sp always points at the last pushed value, so for pop i have to read, then subtract

That doesn't line up with how you define push currently:

Write the 32-bit value word2 to the stack at address sp, then decrease sp by 4

[badlogic]

Sadly, ou only get addition/substraction for free :/

I'm gonna fix up the push semantics!

[binji]

Nope, multiply works too! We use that fact in WebAssembly. You can also see that the same code is generated in godbolt.

[badlogic]

Ah, I remembered x86 imul and assumed there was a reason for it that I can't ignore.

I do need signed/unsigned cmp though!

[binji]

Yeah, the high 32-bits and flags only make sense for signed, but the low 32-bits are the same for signed or unsigned. And you're right about cmp!

Though you could make the argument that having unsigned makes things more complicated. AIUI Java originally had only signed integers (Though it sounds like they have some support for unsigned now) and I guess it mostly works. I found this SO answer that mentions the design choice.

[badlogic]

Since Wee is supposed to be a learning environment, I believe it's important to expose students to two's complement. Having the defaults signed, but offering unsigned variants when necessary seems like a good compromise imo.

I've added:

• the missing arithmetic instructions
• Specified how cmp and consorts work (NaN & Infinity handling TBD)
• 16-bit load/stores
• Fixed push semantics
• stackalloc to simplify stack allocation

Really appreciate that you took the time to give feedback on this somewhat dry matter. Thanks!