search

jeandrek / do-it

Toy compiled language
GNU General Public License v3.0
2 stars 1 forks source link

Put all lexical context in code generation procedure parameters? #16

Closed jeandrek closed 6 years ago

jeandrek commented 7 years ago

Since initial commit the lexical context used by the code generation procedures has been split between the parameter ENV and the (*shudders*) global stack *STACK* (which was initially just a stack of the stack index for each lexical block but was then extended to contain the number of words that need to be popped for each block after I added block scoping (see #7) and I just extended it to also hold whether the top lexical block is a procedure or not (see #9)).

I could make one combined structure of the environment and what I currently put in STACK\, or I could just use multiple parameters for all the data.

Here is where *STACK* is defined.

jeandrek commented 7 years ago

Huh

jeandrek commented 6 years ago

I think it's appropriate enough to put all of this right into the compile-time environment's frames, if I can't get rid of most of it.

Okay: I pretty much need to keep the offset from the frame pointer. The rest all depends on how RETURN will be implemented (not that great as it is…).

jeandrek commented 6 years ago

Well, the number of bytes that need to be popped is just the offset from the frame pointer if the current block is a procedure, or that minus the offset of the previous compile-time environment frame otherwise. So all I really need to know other than that is whether or not the current block is a procedure, so you can just go (= (length env) 2). (And then *toplevel* is just (= (length env) 1).)

…Actually, as long as at the top level the offset from the frame pointer is always 0, there only needs to be one case and you can forget about all of that… (It's only a problem in the first place because procedures are compiled as if they were in a sub-environment of the top-level environment but of course they aren't really.)

jeandrek commented 6 years ago

Maybe instead it should just pull all the definitions out when compiling a procedure and allocate the locals with a SUB, and then RETURN will just jump to the end of the procedure (unless it has no locals.)

Edit: This is what I'm doing. Statements like (defvar x (+ a b)) internally become (defvar x) (set x (+ a b)). I'm not sure yet about defining variables in places other than the top level of a procedure (though I'd like add nested procedures eventually…)

Also, I'm probably scrapping block since it is pretty redundant.