Manual Stack Alignment

[enusbaum]

So, in x86 you can modify ESP to manually align the stack.

We know through documentation that, for the sake of this robot, EBP will always be $FF.

On that node, I have a couple questions/enhancements:

• Would there be value in adding an OP Code to manually set the stack pointer?
• Would there also be value in adding an $SP variable which would always represent the byte of the current stack pointer?

An example being if I needed the second float from an IO that returns two, I could s_align $SP+4 then popf the value I need.

My thought here is that this would result in fewer instructions, variable declarations, etc. since the name of the game here is code brevity. I know this CPU doesn't support "registers", but I think stack alignment is a pretty basic feature.

Thoughts?

[krisives]

Getting and setting the stack pointer (SP) could be done via two new opcodes. Kinda strange to be pushing the stack pointer into the stack itself, but that's the only way to do it.

[enusbaum]

My thought with that is a op code to push the stack pointer to the stack wouldn't result in any code savings.

For my example, it would be:

s_align $SP+4
popf _second_value

Where as the proposal would be:

s_position
push8 4
add8
s_align
popf _second_value

Again, I know the VM isn't setup to use registers, but it can use $XX to directly address memory, could we add another mnemonic for state values? Like '@' for state values such as:

• @SP == Stack Pointer Address (byte)
• @EP == Execution Pointer Address (byte)
• @CLOCK == Current CPU Clock Value (byte)

etc.

[MLanghof]

Would peek8 (and peekf) satisfy your needs if it existed? It would pop an offset o from the stack and hand you the value at SP+o (well, 0xFF - SP - o to be precise). I know, that in itself is awkward because you actually change the SP while doing this, but it would be on the same level of complexity as the other stuff.

What's definitely not going to happen is arithmetics in instructions. Even if $SP meant what you wanted, you couldn't have $SP+4 in an instruction. s_align could directly take an offset, but then a potential peek8 would have extremely similar behavior to your suggestion (with s_align replaced by push8).

(Side note: You'd have to subtract 4 from the SP instead of adding it if you wanted a value lower on the stack. Also, $ currently denotes hexadecimal numbers, not variables or literals.)

[enusbaum]

The more I noodle on it, I think only one instruction would be needed here to achieve what I was originally talking about.

s_align byte -- Align the stack x bytes (positive or negative)

I can't think of an instance where knowing the stack address would be beneficial. I can only see using manual alignment if I wanted to just skip over a result from an IO that pushes multiple values.

[MLanghof]

Well, to be fair, I could see a point in being able to set the stack pointer: Resetting SP to 0 whenever you enter your main loop. That would free you from having to care about popping all the stuff that was on the stack when you went to handle an event (e.g. item or hazard detected). I don't think this is a good motivation though.

For s_align, do you simply mean offsetting the SP? Because in that case, that's already reasonably easy to do (pop8 wayne to move down 1, popf wayne to move down 4, etc. for push). It would only save instructions if you were to s_align for more than 1 or 4 at a time in either direction.

[enusbaum]

It would save address space for a float I might never use that would have otherwise had to be assigned to a variable to pop off the stack.

I only mention this because the accelerometer currently returns multiple floats on the stack. I'm unsure the plan in the future for the additional IO commands (radio, etc.), but if there's a chance of 2+ values being pushed to the stack, it just seems like something that should be there.

You gents know what's coming down the pipes feature wise, so I'll leave it up to you. 👍

For me, this is obviously just a nice to have.

[krisives]

You gents know what's coming down the pipes feature wise, so I'll leave it up to you.

Not entirely, a lot of what gets done is based on the feedback from everyone on Gtihub or in the chat room. The only problem is we are very limited in how much we can change the VM instruction language. Right now it's possible to do it within a 1-byte instruction for a byte, but it would take a two byte instruction to do it for a float.

[enusbaum]

Signed byte should be enough. I can't see, realistically, how anyone would need to align the stack beyond -128 to 127. Beyond that point, you're saying that half your VM memory is stack.