search

wiz-lang / wiz

A high-level assembly language for writing homebrew software and games on retro console platforms.
http://wiz-lang.org/
Other
409 stars 40 forks source link

Local variables / static stack frames #59

Open Bananattack opened 5 years ago

Bananattack commented 5 years ago

(I've written about this a bunch on Discord in the past and offline, but apparently never made an issue for it. ;3;)

Recently I heard about a LISP-like 6502 language by dustmop called 'co2', that allocates variables on a 'compiled stack', and this reminded me once again about this.

This would be a very cool feature to have automatically allocated locals in Wiz, as opposed to just aliases for existing storage.

I've wanted it a way for a while to build a statically-allocated / non-recursive stack frame, by analyzing the call graph of the functions. The big caveat is that this prevents recursive and re-entrant code. It could be an attribute on functions to opt-in to non-recursive functions. Or perhaps the opposite, assume non-recursive unless specifically asked (and raise a compile error if call cycles occur). To avoid attributes, it could also be configurable at a top-level, somehow.

Maybe the default stack model could be defined on each platform (eg. maybe platforms with stack-relative addressing like the 65816 could automatically prefer this?)

The main issue is 'where' to put the RAM variables, because Wiz doesn't know what RAM address area is free for general use in the program. But for simplicity's sake, maybe it could look for an array of u8 with a specific name, and use that area to allocate storage for RAM vars.

Or have a builtin opaque variable type for holding this static data stack, that is has unknown size until link-time, and places that use these opaque declarations are. Keyword: ??? (fixedstack? stackframe? compiled stack)

Allowing local vars and arguments would mean less var foo : u8 in temp0; declarations in function signatures and bodies, and make the use of T in storage for only when you need to care where something is passed.

undisbeliever commented 5 years ago

I like this idea. Automatic local variables and access to a call graph would make development a lot simpler.

My own $0.02: I would not be using the stack relative local variables on the 65816 if offered. The 65816 stack relative addressing is rarely used as adjusting the stack pointer involves multiple instructions (a16(); tsc ; clc ; adc #<OFFSET> ; tcs) and is usually not worth the cost.

Bananattack commented 5 years ago

Oh right, I forgot about that. I guess I would probably focus on the static stack frame / compiled stack idea anyway.

stack-relative seems nice for recursive and re-entrant code, but it's kind of a rarity. with that kind of overhead, I would want it to be opt-in.

On Wed., Sep. 11, 2019, 6:39 a.m. Marcus Rowe, notifications@github.com wrote:

I like this idea. Automatic local variables and access to a call graph would make development a lot simpler.

My own $0.02: I would not be using the stack relative local variables on the 65816 if offered. The 65816 stack relative addressing is rarely used as adjusting the stack pointer involves multiple instructions (a16(); tsc ; clc ; adc # ; tcs) and is usually not worth the cost.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wiz-lang/wiz/issues/59?email_source=notifications&email_token=AAAXLHZARSEPGTU2JXRZOGLQJDDE3A5CNFSM4IVNQWEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6OBYNA#issuecomment-530324532, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAXLH67L2YCGWJ2O5Y3WT3QJDDE3ANCNFSM4IVNQWEA .