[Tinyos-8051wg] Working with SDCC

[Martin Leopold]

Hi All.
I've spent some time trying to get experience with sdcc. While this in
general has been a rather unpleasant, I'm still not very fond of the
alternative (Keil). These are the issues I've encountered while working
with sdcc:

Inline'ing, code size
=====================
As mentioned previously inline'ing is not around the corner for sdcc,
further more the generated code size is typically larger than Keil. Both
of these are performance issues, that could be showstoppers for sdcc.

Assembler
=========
Sdcc includes an old version of asxxxx[1]. It is unclear which version
exactly. The discussion on the mailinglist suggests asxxxx 1.70 while
some of documentation (doc/README) suggests the version named CUG292,
while others suggest 1.70. The assembler has been kept back becuase of
license issues.

The assembler is updated in some areas included memory banking, in what
way this constrains sdcc is unclear to me.

Filename handling
=================
SDCC and helper utils have horrible filename handling - especially when
attempting to debug. While it is simple to rename files it is highly
annoying. The code is a mess, and changing it is tedious.

Debug facilities
================
The debug facilities of sdcc are buggy and limited. Debuging comes in
the form of the simulator s51[2] and sdcdb. When compiling for debug
sdcc augments the .asm output and produces an additional "debug-info"
file. The debug and asm files are read by sdcdb that can displays
dis-assembly on a C-function basis, etc.

Displaying the C-source and asm intermixed from sdcdb is as far as I can
tell not supported (yet), but the .asm file is annotated with
line-numbers from the C-source, for this purpose I assume.

[1] http://shop-pdp.kent.edu/ashtml/asxxxx.htm
[2] http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/ucsim/

-- 
Regards Martin Leopold.
Dept. of Computer Science, University of Copenhagen