A proposal for freestanding environment target

[flysand7]

Introduction

In this proposal I propose a new target for the Odin compiler and it's requirements based on my experience of trying to write an OS kernel in Odin and inspections of the resulting binaries. I didn't read that source for Odin compiler and I don't know how the features of the current targets are being implemented, so please note that some things I say are based on the empirical knowledge.

The freestanding environment is meant to be used with certain low-level userspace applications (applications that run under a certain OS), as well as OS kernels and embedded devices. These programs are typically restricted in the operations they are allowed to perform, for example memory allocation, IO, bounds checks, as well as certain restrictions in terms of their runtime. Though it should be noted that some freestanding programs may be able to set up the necessary control structures that let them allocate memory or access the IO.

So the new freestanding target should only restrict the mechanisms by which the program is started up, while providing the ways by which the program running in the freestanding environment can set up other features like bounds checking or memory allocation.

Startup/Linking requirements

Freestanding program should not have any Odin functions that call the freestanding startup functions, i.e. there should be no runtime startup and initialization. The reason being that the runtime startup functions may make some assumptions which aren't true at the time the program is started, e.g. that SIMD is enabled or that the processor stack is set up properly.

Currently the global structures are initialized by the runtime. That said, it may be possible to define that the runtime startup function with the necessary minimum assumptions and simply leave it in the object file. It is the job of the freestanding program to setup the environment and then call that function.

One thing that may be a problem here is the fact that Odin programs may require certain runtime set-up, leaving them unable to execute any code, including the pre-setup. Currently I'm not aware of any features in Odin like that, thanks to Odin being a relatively low-level langauge. Even SIMD, which is required basically by every part of the Odin program can be required by a call to an assembly function before any other code is ran.

Bounds checking

Current bounds checks are performed by calling runtime.bounds_check_error function and if a freestanding program defines its own bounds checking function (a function with the same link name) the compiler crashes. Therefore the requirement is the following:

If a freestanding program compiles with bounds checks, the compiler expects that program to define a bounds check function. For example the compiler may generate a call to runtime.bounds_check, and it is the job of the program to define a procedure with that link name. Then the call will be resolved by the linker.

As a side note I wonder if using MMX is a better idea to use for the bounds check on Intel processors.

Note on the program startup

The requirements listed above are meant to be used by the programmers in the following way: whenever their program starts up in implementation-defined way, it first has to set up the processor state and the runtime in such a way that Odin functions can be used. It's not the job of the compiler to generate the appropriate instructions, because areas of use differ wildly.

The program startup can be coded in either assembly or Odin code. In the latter case the programmer will need to take note of what features of the language can not be used. For example no structure, including the context can not be initialized until the SIMD is enabled, therefore SIMD enabling has to be the first thing to do. Since the startup process is short in terms of code size it's not a problem if the programmer needs additional mental effort and knowledge to get the program running.

Conclusion

The way bounds checking works and the way the runtime is initialized needs to be modified. So far I have not identified any other part of the Odin compiler that needs to be modified for freestanding used. If there is anything else I will post additional details to this discussion.

[flysand7]

I found one more thing. Just realised that -no-assert didn't do what I was thinking. Here's one more:

Assertions

A freestanding should be able to define its own assert procedure, in a way similar to bounds checking.

[flysand7]

Here are addends as per our yesterday's convetsations in the Odin discord:

(Related) Disabling SSE, AVX, MMX

Whenever an system call or hardware interrupt is issued, the processor switches to executing a special interrupt handler procedure. Unlike normal procedures these procedures need to save all the state of the processor that they can overwrite. This includes all general purpose registers, and if that procedure uses SSE, AVX or MMX those registers need to get saved as well.

The problem is that the store for those registers in total is on the order of 512 bytes, and it's a whole half kilobyte store every time any application calls the OS or a hardware interrupt is issued. Most OS don't benefit from SIMD and MMX as much so they opt out of SIMD to not have to store that much data.

This feature could be made available for all the programs, not just the freestanding programs. There's nothing specific about freestanding that should make it the only platform with disableable CPU features.

Red zone disabling

SysV ABI defines a 128-byte red zone that needs to be disabled. A flag might be a good idea.

Note on "c" callconv

The "c" calling convention is defined to be the standard calling convention to be used with the C programming language on a given platform. However "freestanding" is not a specific platform, therefore it wouldn't make sense to pin it to a specific calling convention. It would also make the compiled code non-portable because the "c" calling convention is potentially different on different host platforms.

If a program needs to e.g. call UEFI API or anything similar to that, the API has to get explicitly bound and the calling convention explicitly specified. Something similar has been done to practically all Odin bound API's in existence, so there's no problem.

[gingerBill]

Does "c" calling convention need to be disabled or is it good enough having it default to sysv or win64?---because you already specify it with freestanding_amd64_sysv.

[flysand7]

I don't understand why the freestanding target needs to define it's own calling convention. It works perfectly fine when all the internal functions of an embedded program use the Odin calling convention, the same way as in all other Odin programs. The only places freestanding program actually needs to use a different calling conventions are:

• Startup
• API calls
• Callbacks

The calling convention for those can be specified specially, the same it is done for all other Odin programs.

I'm not aware of any freestanding environment that specifies the calling convention depending on an architecture and whatnot. Even UEFI which is meant to be used on all different kinds of processor uses the win64 calling convention regardless of hardware.

So my conclusion is that it's not useful to make "c" synonymous with "sysv" in freestanding environments, nor is it useful to define a special calling convention for these environments. The usage of "c" calling convention in freestanding environment should be an error. This makes Odin a bit more consistent and it also helps preventing certain kinds of errors that are rooted in wrong assumptions.