c compiler for hack cpu

[pm100]

here is a c compiler for the hack cpu. https://github.com/pm100/hack_cc

There are a few sample apps - including tetris !

Note that the code generated by the compiler quite often wont run in the 'legacy' desktop emulator because it uses the free RAM space beyond the screen buffer and the desktop emulator doesnt permit that. The web UI does allow it but that runs too slow to usefully run tetris. I have several other emulators

- there is a WIP IDE , emulator and debugger in https://github.com/pm100/hackem
- there is a simple python emulator in https://github.com/pm100/hack_cc
- there is a standalone c++ emulator using the excellent one lone code pixel game engine in https://github.com/pm100/hack_olc

I also have a 'fixed' version of the desktop ide that allows high RAM addresses

At the moment the main oddness is that an int (16 bits) is not the same size as 2 chars (as required by posix), a char also occupies 1 word so we can address each char in a string. I am working on an option to make a 16 bit int occupy 2 words, so that you can address the ho and lo byte separately

[dolomiti7]

Great work! I always had a C compiler on my bucket list as well... What do you mean by allowing high RAM addresses? In your docs I saw that you are using 32767 as a kind of terminal output port. Do you have any other uses for the high RAM addresses in your code? Like a second RAM area? That would allow some 80s style RAM expansion techniques like EMS expansion cards that allowed the 8088 IBM PC to address more than the 20-bit 1 MB limit with a hardware+software paging... ;-)

[pm100]

Regarding high memory.
The RAM memory map is basically
- 0x0000-0x3fff general purpose
- 0x4000 - 0x5fff screen memory
- 0x6000 - kb input
- 0x6001 - 0x7fff general purpose

The 'legacy' desktop (java) IDE does not allow read or write above 0x6001, there is no reason for this blockage.  It has this line

    public static final int RAM_SIZE = 24577;

The web GUI  has the full RAM size of 32k words

[c0ff33]

In the original HACK spec the >= 0x6001 address range is explicitly defined as invalid so a strict interpretation is correct to not let you address it as the HDL does not map a part with 32K words of memory for RAM.

In practice if the memory was available it would be addressable, up to 56K is addressable with some changes to the ABI (e.g. using 1 bit instead of 3 for the A/C instruction flag).

[c0ff33]

Possibly I was just doing it wrong but when compiling Tetris.c in hackem format the resulting binary was just a garbled display buffer. The original Tetris.hackem shipped in hack_olc appears to work as intended but there was no copy of tetris.c in hack_olc/demo as described in the docs.

hack_cc ../hack_olc/tetris.c -I include/ -f hackem

The following build steps work to compile hack_olc on Linux for me:

cmake -S cpp -B cpp/build -G Ninja
cmake --build cpp/build

Nice work though & thanks for sharing, I had idily wondered how much work something like this would be and PGE looks interesting. I think I've seen only one other aborted attempt to do something like this which was trying to write a LLVM backend previously and Jack2c was going in the other direction to compile Jack natively.

[pm100]

The copy of tetris.c is in the root of hack_olc. The one referenced later is in hack_cc/demo. They are the same at the moment

I ran the exact compile you did and it creates a valid tetris.hackem file

hackem v1.0 0x0010
ROM@0000
01a8
ec10
0000
e308
0000
ec10
000d
e308
4bb5
ec10
000e
…..

FYI I compile with –map too, produces a memory map of the generated ‘binary’

To run the binary you need to load it into an emulator – which one did you try? And how did you run it

[pm100]

The web based tools - the 'modern' set - accepts memory access above that limit, my c generated code runs fine on it, you dont need any extra bits, 32k words is fully addressable 0x0000-> 0x7ffff. The desktop emulator has a test that blocks addresses > 0x6000

5.2.4 ..... read write RAM device consisting of 32k addressable 16-bit registers

fig 5.6 is silent about the RAM in the address range > 0x6000