>> On one hand, IMO the pic ports have great potential - it is a popular
>> architecture which AFAIK is not supported by other free compilers. On
>> the other hand the ports are in really bad shape, the pic architecture
>> is weird. And the ports are somewhat different from the other ports
>> making it harder for sdcc developers familiar with other ports to make a
>> change there.
Even I do not fully know the pic ports, and I consider myself their
maintainer for the past ~7 years. They have seen at least 3 developers
in the past (including me), and each one of them has apparently added
an optimization pass (often adding another intermediate representation
of PIC opcodes / operands as well) to the code, before it generated
(near-)error-free code. We now have (a) peephole optimization, (b)
broken optimizations of several code sequences (remove2pCode or how
they are called), (b) my dataflow-based optimizations and goto
optimizations, (c) an upcoming similarly data-flow-based optimization
from the currently reviewed patches sent in by Molnar (I probably
combined pic14 and pic16 optimizations, but that's not the point
here). While this addresses the code size issue -- and apparently at
the wrong end, leaving the code still too large -- it does not get us
anywhere closer to a sufficiently working backend.
> However the generated PIC code is huge. A better register allocator and an
> overlaid memory allocation instead of the stack would be very nice.
> For the moment all functions are reentrant, this means that the large majority
> of opcodes in a sdcc-compiled pic program are spent moving things around the
> stack. lots of things. That could be once and for all in some fixed place
> instead of the stack, just like the mcs51 does.
> I understand that z80 and hc08 are your priorities but based on mcu popularity,
> some help on the pic port would be nice.
Currently, the pic ports are huge, unstructured, incomplete; they
retain relics from the port they once were based on (mcs51?), and
seemingly lose important information (e.g., about volatile operands)
during the optimization passes.
I have seriously considered starting the pic port(s) from scratch,
with a cleaner code structure, properly handled common options (such
as reentrancy on demand), and better support for new instructions in
the PIC16 devices. I am, however, scared off by the work others (such
as Molnar) have put into the current ports and by my lack of time.
> I already sent several messages and attempted to raise some interest by starting
> to write patches, but all of this seem to have been sent to a black hole
> somewhere in the wild... For example, following up my attempt to work on
This is probably (and sadly) true for some other patches as well. I am
aware of the fact, and I apologize. Unfortunately, I have had to
change jobs a year ago and now find even less time for sdcc than
> multiple sections, I'm completely unable to understand how I could sort
> functions by section so that the generated assembly can be used by gputils,
> which has no support whatsoever for multiple entangled sections. I looked at the
> code, there's one single global ORG variable that gets updated for every function.
This is one of the problems I expressed above: The pic ports have no
clear structure, so a lot of information vanishes while transforming
the iCode list into pCode chains and during optimizations transforming
the latter. I cannot tell you how to proceed -- I don't know myself.
You can probably add more hashtables mapping function names to section
names and a set / "inverse" hashtable providing all the section names
in use, so that you can dump the functions in the proper order
(following some section preamble). Unfortunately, such attempts have
been done in other places as well, the result being the "intuitive"
code base that we currently have :-]
> Who else is interested in improvements to the pic ports?
This question is probably more relevant on the sdcc-user list. The
other developers have their hands full with their ports, though most
of them seemingly would like to see the pic ports catch up.