EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

building xr16 lcc compiler

Started by Rob Finch November 17, 2004

Has anyone tried building the xr16 lcc 'C' compiler using visual c++
version 7, instead of version 6 ?

It seems to build everything fine, but the resulting compiler croaks
with the message

#line 1 "<stdin>"

when you try to compile something. Rob



I remember seeing that. It has to do with some environment vars being too
long or something like that. If you do an lcc-xr16 -v you should see the
compiler passes that the lcc-xr16 driver is trying to run, and then can
narrow down the problem. You might have to set INCLUDE="" or similar to work
around the problem.

Please let us know if that does the trick. Otherwise I'll unpack the XSOC
distribution and see for myself.

Jan.




--- In , "Jan Gray" <jsgray@a...> wrote:
> I remember seeing that. It has to do with some environment vars
being too
> long or something like that. If you do an lcc-xr16 -v you should
see the
> compiler passes that the lcc-xr16 driver is trying to run, and then
can
> narrow down the problem. You might have to set INCLUDE="" or
similar to work
> around the problem.
>
> Please let us know if that does the trick. Otherwise I'll unpack
the XSOC
> distribution and see for myself.
>
> Jan.

I eventually managed to get past that problem, by setting "include="
before running lcc. It looks to me like a problem with the operating
system _spawnvp function not handling quoted strings as parameters
correctly.

Anyway, now I have a new problem. It looks like the compiler doesn't
know when the program ends. I tried compiling fib.c and got these
error messages: (line 20 is the last line of the program). It looks
like it scans past the end of the file, and picks up the directory
path.

fib.c:21: `0' is an illegal array size
fib.c:21: syntax error; found `:' expecting `;'
fib.c:21: skipping `:'
fib.c:21: syntax error; found `:' expecting `;'
fib.c:21: skipping `:'fib.c:21: illegal character `\'

fib.c:21: illegal character `\'
fib.c:21: syntax error; found `butterfly' expecting `;'
fib.c:21: illegal character `\'
fib.c:21: syntax error; found `software' expecting `;'
fib.c:21: illegal character `\'
fib.c:21: syntax error; found `bfcc' expecting `;'
fib.c:21: illegal character `\'
fib.c:21: syntax error; found `bin' expecting `;'
fib.c:21: illegal character `\'
fib.c:21: syntax error; found `cpp' expecting `;'
fib.c:21: syntax error; found `.' expecting `;'
fib.c:21: skipping `.'
fib.c:22: syntax error; found `argv' expecting `;'
fib.c:22: syntax error; found `:' expecting `;'
fib.c:22: too many errors Any ideas ? Is there a way to run lcc in the debugger ? Rob





> Anyway, now I have a new problem. It looks like the compiler
doesn't
> know when the program ends. I tried compiling fib.c and got these
> error messages: (line 20 is the last line of the program). It looks
> like it scans past the end of the file, and picks up the directory
> path.
>
> fib.c:21: `0' is an illegal array size
> fib.c:21: syntax error; found `:' expecting `;'


I managed to figure this problem out. To debug the earler problem I
had put printf's in lcc. The lcc preprocessor was picking up the
printfs and adding them to the program. As soon as I removed the
printfs everything worked.

Rob





I haven't started to compile the port (but I bought the book,
etc.). In the end, what worked?

I have Visual Studio .NET 2003 and Visual C++ 5.0 as well as the
usual suspects on Linux and I would like to take the easiest path. --- In , "Rob Finch" <robfinch@s...> wrote:
>
> > Anyway, now I have a new problem. It looks like the compiler
> doesn't
> > know when the program ends. I tried compiling fib.c and got
these
> > error messages: (line 20 is the last line of the program). It
looks
> > like it scans past the end of the file, and picks up the
directory
> > path.
> >
> > fib.c:21: `0' is an illegal array size
> > fib.c:21: syntax error; found `:' expecting `;' > I managed to figure this problem out. To debug the earler problem
I
> had put printf's in lcc. The lcc preprocessor was picking up the
> printfs and adding them to the program. As soon as I removed the
> printfs everything worked.
>
> Rob



Rob Finch wrote:
>
> Has anyone tried building the xr16 lcc 'C' compiler using visual c++
> version 7, instead of version 6 ?
>
> It seems to build everything fine, but the resulting compiler croaks
> with the message
>
> #line 1 "<stdin>"
You may need fine tuning on the default paths of the compliler
for searching for include files or default extensins like .h





I don't know if this is a problem with the xr-16 compiler or not, but
I found it while working on a compiler for the Butterfly processor.
(The xr-16 seems to handle things the same way).

Because the processor doesn't support triples for registers (eg add
rt,ra,rb) I had them coded like this:

mov rt,ra
add rt,rb

This would seem to be okay, but it turns out not to work sometimes
depending on where the compiler places registers.

eg if rt and rb are the same register above, then it doesn't work
because it generates code like this:

mov r1,r2
add r1,r1

A solution is to use another (preassigned) register and another opcode

mov r13,ra
add r13,rb
mov rt,r13

It's ugly, but it works. Rob



> eg if rt and rb are the same register above, then it doesn't work
> because it generates code like this:
>
> mov r1,r2
> add r1,r1

You want to use a conditionally squashed mov instruction. See this excerpt
from my DesignCon2001 paper
(http://www.fpgacpu.org/papers/soc-gr0040-paper.pdf):

"For this project, the author ported lcc to gr0040. This
involved creating a new machine description, derived from
the pre-existing xr16 machine description, by changing only
40 lines of code. Here's a typical change:
< reg: ADDI2(reg,reg) "add r%c,r%0,r%1\n" 1
---
> reg: ADDI2(reg,reg) "?mov r%c,r%0\nadd r%c,r%1\n" 1
"This is an instruction template that describes how to add two
arbitrary general purpose registers r%0 and r%1 and store the
sum in register r%c. On xr16, there is a three-operand add.
On gr0000, there is not. Instead, this gr0000 template says to
(optionally) move r%0 to r%c (if r%c is not r%0) and then
add r%1 to r%c."

So if you are careful to put a '?' in front of your mov instruction, it will
be elided when r%c equals r%0 and you won't need a scratch register and the
second mov.

In my opinion, this '?' trick is a hack. But it shows that Fraser and Hansen
were not above making a simple change to lcc itself to make it easier to
generate something from a .md file, when problems arose there. (In other
words, were '?' not already implemented in lcc, we should all feel we are
granted sanction to modify lcc proper with facilities like '?' if we need
them. We don't have to stick exclusively to .md file facilities to the
extent they currently exist, if some additional functionality would build a
solution that is better (simpler, etc.).)

(Do you have the lcc textbook? And regardless, it is also helpful to read
each of the machine descriptions for the other processors in the lcc
distribution (e.g. i386, sparc) because each contains tricks you might apply
to your own .md. I believe either i386 or sparc uses this '?' facility.)

Cheers.
Jan Gray



The 2024 Embedded Online Conference