On 15/05/2016 11:25 PM, Martin Nowak wrote:
On 05/15/2016 02:17 PM, Daniel Murphy wrote:

For simple types that's true.  For more complicated reference types...

Variable indexes are not enough, you also need heap memory, but slices
and pointers (and references) can refer to values either on the heap or
the stack, and you can have a slice of a member static array of a class
on the stack, etc.  Then there are closures...

So we do need a GC or RC for arrays, structs, classes (anything
heapish). Values for those could be allocated by a simple bump/region
allocator or a dedicated allocator that support individual freeing (via
RC or GC).

In any case struct Pointer { int index; /* 2B positive values for stack,
2B negative for heap*/ } wouldn't be much more complicated than a raw
pointer (and a bit simpler to garbage collect).

The problem is, if index refers to a single variable on the stack, then it's insufficient to refer to a variable inside an aggregate on the stack. Then you need to start building constructs for member of struct in array of struct pointers and it gets fairly messy... It's all solvable, I'm not sure the simplicity would survive.

Neither e2ir or s2ir are actually that complex.  A lot of the mess there
comes from the backend IR interface being rather difficult to work with.

Think of a simple switch statement where you even need to introduce
relocations (or keep a list of fixup addresses) b/c you don't know the
jump addresses in advance.

This is not exactly difficult to do.

In a visitor you simply test the cases and execute the first case body.

Not to mention that we can reuse existing solutions from the current
interpreter (e.g. for gotos see

Flow control is really not where the complexity lies IMO. The weird ways in which different types of reference types can combine leads to either very complicated or very low level descriptions of memory.

Reply via email to