m0 C implementation TODO

TODO.md

• implement both signed and unsigned integer division/remainder ops
• make callframes variably-sized
• add hashtable implementation: necessary for CHUNK_MAP/linking stage
• use unions instead of uint64_t as register type
• namespacing cleanup (prefix external symbols)
• add structure for strings
• make integer size configurable or mandate 64-bit integers

Are you thinking that we make only the integer size configurable? Since all registers are actually the same in M0 (there really is no difference between an integer register and a string register), it seems that all register types need to be the same size, according to the current spec.

In any case, I am all for making it a compile-time option to decide whether to have registers be 16/32/64/etc bits wide.

Most desktops are 32/64bit, but 16 and other widths are common on embedded devices.

@leto My main concern is the m0 C implementation, which currently unconditionally defines registers as uint64_t and stores pointers via casts (zero-extension on x86, noop on x86-64) and integers via type-punning through pointers (which is equivalent to using unions). However, the use of integer type is inconsistent (sometimes it's int - ie 32-bit on both x86 and x86-64 - whereas the new isgt op uses int64_t).

However, integers need not use the full register size: On x86, using 64-bit registers so we can store doubles together with 32-bit integers is the most efficient choice for JIT compilation (using 64-bit integers on x86 leads to a lot of register spilling).

My choice would be to have 2 integer types: a word-sized type and a type with configurable size (which would default to 64-bit). This new word-sized type would be used for pointer arithmetics/indexing (ie the m0 equivalent to the C types size_t and ptrdiff_t).

Seems reasonable. Just to be clear, would all register types have a word-sized flavor and a configurable flavor? Or only integers? And is this a compile-time only option, or something can be changed at runtime?

Having two flavors only makes sense for integers, imo, and even that is open to debate:

On the one hand, it adds complexity as we'd need another set of ops. On the other hand, we probably want 64-bit integers on 32-bit architectures, but if this is the only integer type, we'd have to truncate integers every time we want to do pointer arithmetics (and things like loop counters mostly don't need 64-bit precision). However, a good optimizer can help with that (see Javascript, which doesn't have an integer type).