NetBSD/sparc 1.1 port of lcc-3.5 ANSI C compiler 0 of 1

NetBSD/sparc 1.1 port of lcc-3.5 ANSI C compiler 0 of 1

Post by Bruce Edig » Tue, 20 May 1997 04:00:00

I've done a port of Hanson & Fraser's "lcc" ANSI C compiler to
NetBSD/sparc 1.1.  Please find attached the "README" file.

To get this port working, you'll need to get lcc-3.6 from the official
lcc web site:, the rest of the
files for NetBSD (in another usenet post), and perl.  The attached README
explains the embarassing reason for needing perl.

---README file---
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:

  (A) 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 divisibl-by-8 address.

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

      3. Outputs "stabs" for NetBSD's gdb.  The original output stabs for
         Sun's old a.out dbx de*.  Apparently, there are differences.

         stabs 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.

  (B) The compiler driver ("lcc" 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

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.