Compiled Output

Brainstorming
1

I don’t really know if this even falls under brainstorming, it was just a silly thought that came to mind, and I was curious if it exists/has any usability at all.

So, the lowest level of speaking to the machine that one can interact with is assembly/machine code. People then construct languages that abstract this away so that, by means of a compiler, the actual logic of the code can be encoded into multiple assembly language outputs.
In doing so, however, these higher-order constructs must be made concrete. E.g., if you have an “enum”, that has to become some data in either a register or in memory that can be updated.

So, I know in Zig you can specify the underlying type (e.g. enum (u8), if I recall), but, say one didn’t, when one compiles, could the output include what the concrete “type”(?) was set to? Would such a thing make understanding the state of memory better/easier without having to look at the full assembly output generated?

I use enum as the example as it’s what came to mind most readily, but hopefully my abstract proposition/question is somewhat clear.
To attempt another example, considering C, you write “int v = 30”, that the compile step would have in its output the concrete choice of “u8” or something.

2

There’s kind of a conflation of things happening here. In Zig, types don’t exist at runtime, so in that sense, no you cannot see what “concrete type” an enum matches up with.

Instead what exists at runtime are locations in memory to write to and read from, and code that treats that memory in variously chunked sizes. So in that sense yes, if an enum is determined to take up one byte in memory, @sizeOf() will return 1 for it.

For structs with auto layout, you can understand the layout in memory with builtins like @sizeOf and @offsetOf. The auto layout is subject to change from compilation to compilation, of course, so it’s a programmer error to rely on these outputs remaining stable across compilation units, etc.

2 Likes