Targeting a Compiler for Tagha and Tagha's Specifications

Introduction

Tagha itself, though I wish to have an official compiler for it, is not meant to be tied down to a single compiler. Similar to how C itself has many compilers for it. Tagha is only meant to be a minimal runtime that has the bare minimum computation necessary to run C code and to use such C code in an abstracted way.

To be a worthy abstracted C runtime environment, giving Tagha runtime speed is a hard requirement.

Tagha C specification

• A compiler targeting Tagha must be able to support all or most of the C11 standard concerning runtime. (Tagha cannot do multithreading as C11 demands given its implementation and purpose unless the multithreading is through natives).
• double and long double should always be 8 bytes.
• float is defined as 32-bit single precision as defined by the IEEE.
• Tagha's push and pop operations manipulates the stack by 8 bytes.
• Local function data should be aligned by a 16 byte boundary.
• long, size_t, and long long should be 8 bytes in size.
• all binary math operations assume both operands are the same size.
• all binary floating point math operations utilize addressing mode sizes to determine whether operation uses float or double.
• Function calling convention is through the registers first and then stack, calling convention uses registers Peh to Thaw for the first 8 arguments, the remaining arguments can then be pushed to the stack. Peh will contain the 1st argument up to Thaw which will contain the 8th argument.
• Function return values always return in the Alaf register (Alaf is the accumulator though general purpose). This includes return values for natives. If the return data is larger than 64-bits, then optimize to have Alaf return a pointer.
• In order to accommodate for natives, Tagha might require a native or host keyword in order to make it easier for the compiler to generate the native information in the header and/or emit native-oriented syscall opcodes. Example would be such as:

// example.h
native int puts(const char *);

If the compiler is smart enough, you may not need this; my original idea was the compiler would differentiate between native and regular functions based on whether the function has a compiled implementation and is used, if there's no function implementation then the compiler could assume the function is a native. Here's a code example explaining this:

// example.h again
void func1();    // func1 declared, extern scope
void func2();    // func2 declared, extern scope

// example.c
void func1()    // func1 is implemented
{
}

int main()
{
    func1();    // func1 is declared, implemented, and invoked, compiles into function call bytecode.
    func2();    // func2 is declared, extern scope, and invoked but not implemented, compiles into syscall bytecode
}

• Calling convention for exported C natives is the same as normal bytecode functions, registers Peh to Thaw will contain the first 8 arguments, remaining arguments are dumped to the stack.
• argc and argv are implemented in scripts but env variable is not implemented (I see no reason to implement as of currently).