On Tue, 2 Apr 2002, michael brown wrote:

> Scott makes allot of sense, and then says:
> > BTW, the 8051 ports of SDCC are quite stable.
>
> Really?  ;-)

Yes Really.

>              I'm using the 8051 version and I admit that the latest
> snapshot is allot better than the "stable" release version, but I wouldn't
> say it was "quite" stable.  It still has some troubles with operator
> binding.  I also have a problem using shifts on the ds390 port.  They can
> cause the compiler to seg fault.  For example:
>     eth_length = ((UI)workbuff[3] << 8) + (UI)workbuff[2];     seg faults
> the compiler
>     eth_length = ((UI)workbuff[3] * 256) + (UI)workbuff[2];    compiles fine
> and runs fine

You're probably using an old version. The stuff I'm working with (which
still has the smell of CVS shink wrapping) compiles this just fine. In
fact the same code is generated for either line (I assume UI is a typedef
of an unsigned int and that workbuff is an array on unsigned chars). The
code generater for the 8051 port looks quite nice. For the PIC port, SDCC
15 or so instructions were generated (type cast bloating)! That code
should only take 4 instructions. How many instructions do Hitech and CCS
take?

I tried to compile this with c2c, but it choked on the typedef's. (Thus
demonstrating my other comment).

> Another sdcc tip:  Use lots of extra paranthesis and type-casting to help it
> to get things right.  ;-)  In all fairness though, I really like it.  It
> works for me and getting around little problems is usually quite easy.  I've
> been spoiled by using gcc on Linux.  It's a really good compiler with a
> decent abiltiy to optimise code.

And to add to this... Make sure you're working with the latest version!
The 2.4.0 March release did not happen. But it should be coming around
shortly.

Scott

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics