Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update to the newer spec #7

Open
lifthrasiir opened this issue Apr 25, 2012 · 3 comments
Open

Update to the newer spec #7

lifthrasiir opened this issue Apr 25, 2012 · 3 comments

Comments

@lifthrasiir
Copy link
Member

Notch will release the newer spec soon (the draft is available here), so the stdlib has to be updated to match with that spec.

Major changes for stdlib:

  • PUSH and POP has been merged (for now), bulk memory operation abusing SP won't work as is.
  • Also the evaluation order of operands has been swapped. Combined with the merger of PUSH and POP this will break almost every code that abuses SP.
  • We now have signed operations. Maybe useful for some cases (given that -1 is available for operands).
  • SP-relative addressing is available, and it does not cost an additional cycle (in the current spec at least). The affects of this change are to be determined of course.
  • Literal as the first operand to get unbranched comparison is not gone, but now slightly inefficient for some cases (no short literal allowed).
  • Trivial assembler changes. (Don't think s/\<O\>/EX/g will work, though)
@Blecki
Copy link
Member

Blecki commented Apr 25, 2012

Merger of PUSH and POP: I was entirely unaware of this. The only time, however, when it made sense to use 'POP' as the first operand in a basic operation was doing comparisons, so this should hopefully not be much of an issue. Does anyone know what 'PICK' is supposed to do?

SP relative addressing : The benefits of this are dependent on the calling convention(s) we choose.

@lifthrasiir
Copy link
Member Author

@Blecki: PICK n is an SP-based addressing. On the other hand, I think that a SP-relative addressing would be useful for a few cases only.

@Blecki
Copy link
Member

Blecki commented Apr 25, 2012

Ah! So it's a mnemonic for SP+n, just as push is for --SP, etc? That makes sense.

As for it's usefulness; those 'few cases' are any time something is stored on the stack. SP+n lets me reference a stack location in no additional cycles. Notice that the most efficient way to reference stack locations without SP+n is that store SP in another register and use relative addressing on that - which DOES cost additional cycles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants