Using Local variables

[neauoire]

Hi,

First off, following the changes to chibicc is exhilarating! Amazing work you two.

The following suggestion is taking advantage of not using Harvard Achitecture, I was wondering if maybe instead of storing all the variables after the main() jump, it would be possible to store the variables locally. What I mean by that is that you could store the variable where it is first(or most frequently requested) as a literal, and have the variable pointer be at the location of that literal.

For example, here, the timer variable is stored localy and not only does it not need to be loaded(it's already a literal) - It can also be written using a single byte with STR.

@on-frame-trap ( -> )
    [ LIT &timer $1 ] DUP #07 AND ?&>no-blink
        DUP #03 SFT #01 AND #30 SFT INC <draw-filepath> &>no-blink
    INC ,&timer STR
    BRK

[hikari-no-yume]

Ah, this would be for local static variables, right? C functions are re-entrant by default, so other locals wouldn't be able to use this trick.

[lynn]

It's hard to use LDR and STR because of the limited range of their operands. We can't predict how large a function is going to be until we codegen + optimize it, so it's hard to know in advance if all the loads/stores are really going to be within 128 bytes of the data. Right now, chibicc-uxn only uses ; and LDA and STA because we can know we can address anything with those.

We'd probably have to compile two "versions" of every function, one using LDR/STR and one using LDA/STA, and then write code for measuring the output (right now the compiler doesn't know that #0004 is 3 bytes and STA2 is 1 byte, etc), and then use the LDR/STR version if (approximating the condition a little) the function+data indeed fits in 128 bytes.

[neauoire]

It's hard to use LDR and STR because of the limited range of their operands. We can't predict how large a function is going to be until we codegen + optimize it, so it's hard to know in advance

Ah yes, that'll be tricky. Probably not worth it then.

C functions are re-entrant by default, so other locals wouldn't be able to use this trick.

Ah! okay I think I originally misunderstood how variables were accessed between functions.

I think there might still be a usecase for globals, maybe.

For example in this screenshot, the LDA2 could be replaced by the actual place where the global is stored, keeping LDA/STA for the rest of the accessing points should keep working. It would make for a smaller program, and one access to a global will be slightly faster.

It might make the keeping of address of the variable in memory through optimization passes more of a headache tho.