Files for a NetBSD/sparc 1.1 version of lcc-3.6. Requires perl (4.036) to compile lcc, and to use lcc as a compiler.

Differences from stock lcc-3.6 sparc distribution:

• Code generator is slightly different

  1. NetBSD's assembler handles the .bss segment slightly differently. Output of .common and .reserve assembler directives is different.

  2. NetBSD's link editor needs symbols for which a 32-bit relocation is calculated to actually be on a divisible-by-4 address. .bss segment symbols are on a divisible-by-8 address.

     Output of name of each symbol is preceeded by an .align 4 or .align 8 assembler directive.

  3. Outputs "stabs" debugger symbols for NetBSD's gdb. The original code generator output stabs for Sun's old a.out dbx debugger. Apparently, there are differences.

     stabs debugger symbols with n_type fields of N_FUN, N_LSYM, N_PSYM are at the end of the code for the function they're associated with, not at or near the beginning.

• The compiler driver (the "lcc" program itself), runs the assembly-language compiler output through a perl script. Apparently, the SunOS assembler implements two pseudo-opcodes that NetBSD's doesn't. The opcodes are st2 and ld2. I could not figure out how to get the lcc compiler to emit pairs of st and ld instructions. It's just not in the lcc-3.6 code-generator- generator's power to consider pairs of 32-bit floating point registers as a single 64-bit fp register. For starters, the code generator never deals with register numbers, only with structs that represent registers. There's virtually no way to get the number of the first of the pair of registers at code generation time.

NetBSD include files are mostly ANSI C compliant to begin with. The original distribution has include files intended for SunOS, which isn't ANSI C compliant at all. NetBSD uses one of the lcc distribution include files, stdarg.h, since the NetBSD stdarg.h is very dependent on the gcc implementation.

I've compiled a bunch of my own C programs, including some with flex, yacc and spin output, and even the twm window manager from the X11R6, patchlevel 12 tree. Of course, lcc itself is re-compiled with lcc.

There are limitations in this port. lcc-3.6 is pretty much stuck on the idea of 32-bit int and long types. 64-bit types, such as "long long" are pretty close to impossible to add to it. The limitation here is that since NetBSD file offsets are 64-bit, system call level file and filesystem manipulation is not possible with this port.

It also requires perl: the compiler driver works over the assembly-language compiler output with a perl script.

$Id$