Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!pacbell.com!ames!skipper!rando
From: rando@skipper.dfrf.nasa.gov (Randy Brumbaugh)
Newsgroups: comp.sys.transputer
Subject: 3L C & the poison constant!
Keywords: 3L C constant bug
Message-ID: <671@skipper.dfrf.nasa.gov>
Date: 7 Nov 90 04:45:36 GMT
Organization: NASA Ames-Dryden FRF, Edwards, CA
Lines: 49

I feel I have had more than my fair share of problems with the
3L C compiler (IMHO).  Now this . . .

The 3L compiler/ assembler doesn't like the constant 0x20800000.
Yes! That's right!  It turns out that this is a very important 
constant for my application.  Here is the input:

func() { asm { ldc 0x20800000; } }

This will produce an error message about an undefined forward
reference. However, either of the following (very similar)
functions will compile:

func() { asm { ldc 0x30800000; } }

func() { asm { ldc 0x10400000; } }

Thinking it was the hex expression it didn't like, I tried good ol'
base 10:

func() { asm { ldc 545259520; } }

Same problem; same error.  Then I thought I had a way to fool the
compiler:  literal bytes of machine code.  (It was VERY important
that I load this constant - it is an address for a memory
mapped i/o register ).

func() { asm { byte 0x22, 0x20, 0x28, 0x20, 0x20, 0x20, 0x20, 0x40;}}

But the compiler caught this and barfed again!  It only seems
to happen in asm statements -- the C compiler can use the constant.
So?  If anybody has an explanation for this that is even close to
rational, I'd really like to hear it!  Or - if the error doesn't 
happen on your system!  I have V 2.0 of the compiler, which I admit 
is one rev out, but this behavior is way out!

If you care, I did fool the compiler and load the constant like this:

func() {
  asm { ldc 0x10400000;
        ldc 2;
        shl; } }

I also figured I could use Norton Utils and patch the .bin file.  These
methods will work while I scrape money together for a Logical Systems
C compiler.

Randy Brumbaugh
rando@skipper.dfrf.nasa.gov