July 28, 2025

Sun 3 bootrom souce - the genassym program

The source for this is in sun3/genassym.c. This is a helper program that is intended to be compiled and run on the host that is building the bootrom. 
./genassym > ../sun3/assym.h
It pulls in (via C "include" statements) a bunch of header files and then extracts and computes values from them. The output will be a bunch of C define statements like this: 
#define SERIAL0_BASE 0xf5a000
#define PARALLEL_BASE 0xf59800
#define TIMER_BASE 0xf5a800

#define NUMCONTEXTS 8
#define NUMPMEGS 256
#define PGSPERSEG 16

#define PME_MEM_VIDEO 0xfe00fe00
I'll note in passing that "locate" finds a sample assym.h file here: 
SS32/sun/stand/src/sc.diag/src/assym.h
This may or may not be informational. We certainly want to generate our own, not use this one.

Making this work on an x86 build host

We need to think about 3 different compilers and how they might handle things differently. We have the original m68k compiler used by sun. We have the m68k cross compiler version of gcc we intend to use. We also have the native x86 compiler that we will use to build genassym.

Some trivial changes (adding stdio.h and stdlib.h to the include list) pop up. Then this catches our attention: 

union longmap {
    long    longval;
    struct pgmapent pgmapent;
};
On the native x86 compiler, a "long" is 64 bits, whereas in the sun3 world it was certainly 32 bits. The obvious thing to do here is to use something more specific like "int32_t" from stdint.h or: 
typedef int u32
However, it would behoove us to inspect every file in the bootrom sources and check how and where long gets used. It probably only matters when we are using the native x86 compiler. Both the original sun compiler and cross gcc for the m68k should have both int and long the same and 4 bytes in size.
Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org