Power working session on the compiler again, but I got it working better. Accessing variables in a more outer scope was not working properly. I think it works now, but it is a really bad idea for performance as the variable is dereferenced multiple times, once for each level into the stack the variable is distanced from the current. The compiler might assign it to a register though.

Added generic switches to the compiler. These work like the _Generic keyword in C. Same idea, but the implementation is a little different. It is a switch based on a type and type cases that must be resolved at compile time. A generic switch acts like a cast expression. Generic switches do not require adding more keywords.

If no default is specified, and none of the types match, the default action is to return an int value of zero. Note that type matching is exact, not relaxed. Note that the syntax is simpler than a regular switch. Block statements are not supported, and the keyword ‘break’ is not required. More complex code can be executed via functions which can be part of expressions.
The typenum() keyword can also be used with an ordinary switch statement to achieve much the same result.

Decided to support the _Generic() keyword.

When FPP was first written about 30 years ago memory space was limited. Consequently, buffers in FPP were quite small. It was limited to 10 arguments for macros. Well, when compiling the standard C library, a macro with more than 10 arguments was encountered causing FPP to error out. A simple fix was to increase the number of allowed arguments to 100, that seems to have worked.

I have begun customizing the standard C library for Thor and the cc64 compiler. Found a number of compiler output errors by inspection. But code generation is looking pretty good. If only I could get the hardware to work.

The compiler was inserting typedefs into the global symbol table instead of the tag table. This meant the compiler could not find typedef’d types properly.

Function prototypes were showing up a zero length functions, which caused them to be inlined, and then there was no inline code emitted to call the function.

The compiler localizes local function names by prepending the name with all the names of the higher level functions. The routine foo() which is local in main() gets called main_foo() by the compiler. I am thinking this may not be the best approach. If one knows the convention then it is possible to call local routines non-locally. It may be better to give local function names a name based on a hash. It would make it less likely they would be called non-locally. With name mangling turned on, the resulting name can be quite long if its several levels deep.

Currently the compiler is referring to float variables indirectly by storing a pointer in a register then referencing the pointed to value, rather than simply storing the value directly in a register. I have not figured this issue out yet. The code should work, but it affects performance. Floats and scalars are handled the same way, and it works for scalars, so it must be close.

There is another issue with the compiler generating multiple copies of switch cases. This leads to a later issue in the compiler with the number of cases processed. One small switch generated 4,000 LOC.

Lots of work on the compiler. It was necessary to have the compiler re-arrange output using temporary files. Data tables which were encountered first in the source file needed to be placed after the code. The issue was the placement of local labels in data tables. To get the assembler to recognize the labels as local all labels had to be made local. The alternative was to use non-local labels for everything. The one exception to local labels is the name of the function itself. It needs to be non-local so it may be called externally. Hence the function label had to be placed first in the output file, meaning the code is first.

Got the compiler to compile the entire Standard C Library.

Adding support for vectors to the compiler. The vectors are specific to Thor. A vector type is a 64 byte bucket that may contain a small array of other primitive types. One challenge is the stack alignment. The stack potentially could be 64-byte aligned but that would waste a lot of space. Not having the stack 64-byte aligned makes it more difficult to handle register spills and reloads. One alternative is to have the processor able to load unaligned vectors.

Ran into issues passing arguments on the stack. A vector is equivalent to four long-integer words.

To support vector masking special global variables were added to the compiler, one for each of eight mask registers. The variables are treated like any other integer variables, except that they may be specified to govern over an expression. Syntax is vmn(<expr>). So, vm0(a+b) applies vector mask 0 to restrict which elements of the vector are processed. Establishing masks is easy. vm0 = 0x3f; would set the low order six bits of the mask.

To declare a vector variable the keyword ‘vector’ is used. So, “vector double dbl;” declares a vector variable containing doubles for elements. The number of vector elements is calculated automatically based on the size of the type specified.

Got rid of the global vector mask variables. This was a bad late-night idea. It is better to allow the compiler to assign a register to use. It turns out I had already coded things this way, but did not find the code when reviewing. A variable can be declared as a vector_mask variable and used in the same way as the global mask variable were, this is slightly more flexible.

Worked on the interrupt keyword. It accepts a parameter indicating which registers to save or load on entry and exit. The compiler does its best to use group register load and stores where possible. Group loads and stores are up to four times as fast as loading or storing individual registers, and occupy ¼ of the memory.

Code for a simple interrupt routine and compiler output:

Looking at all that code, are hardware interupts really needed as a low level construct?
Have all I/O done by I/O processers, and just have hardware message passing for the IRQ software service.
Any real IRQ's would just start and stop processes,in real time, like read a mouse every 1/ 10 a second, or sleep
until next video frame.
Ben.

That is code to save and restore all 64 registers. For most IRQ routines probably saving one or two groups of registers would be enough, especially if written in assembler.
If written in a high level language pretty much all the registers need to be saved and restored, because who knows what register the compiler might choose to use.

The code kind of looks like a butterfly turned sideways.

I/O processors are a great idea. I just have to get around to them.

Have you looked at the latest open PowerPC processor?

Output generated by the compiler looks better all the time. There are fewer crashes and better recognition of valid programs.

I recently copied the test suite, about 200 files to Github. Most of the files will at least compile with no errors. Although generated code remains to be tested.

The assembler code files are simply called .asm files. To be mixed up with .asm files of other architectures. I have been wondering how to compare output for different architectures in the color syntax hi-lighting editor.

Considering adding a section block declaration to the language. It would allow variables to be assigned to specific sections also identified in the linker script. This may be useful for non-cacheable variables and I/O related variables. “C” has a way of specifying the section a variable is in through the __attribute__ mechanism.
A section declaration would work like:
section <section name>
{
Variable declarations…
}

Example:
section bss
{
integer my_var;
}

The compiler currently assigns sections automatically. It places variables without initializers in the bss section and constants in the rodata section. One might want a constant in the text section though or a variable in the data section instead of bss. Or one might want to place large arrays in a non-cached data section. The section declaration would be able to override the compiler’s default assignments.

Rebranded the cc64 compiler as 'arpl' and gave it its own repository in Github.

In the process of updating the compiler, found out that references to stack arguments were not calculated correctly when using the ENTER instruction. The issue was that a while ago the compiler was switched to using 128-bit integers and the argument offset was calculated using only 64-bit integers. So, the argument offset calculation was updated.