Hi Kustaa,

I agree with you in part on this, but it is useful to have a clear answer about the state of the compiler you're working with so you know what you can expect. Its open source so it doesnt need to be sold, and i'm happier to help improve it if I know what its like, rather than assuming its in a stable state and getting disheartened. At the moment i'm trying to setup a TCP/IP stack on a pic18f. The code doesn't compile on SDCC and the current problem is the packed keyword used in the original C18 for a few structs (I've just installed C18 in wine, but havent got as far as compiling it yet). As I don't have much knowledge of the various compiler implementations, its useful to know what issues i can expect to come across with the PIC port. It looks to me like C18 is using some non standard C for interrupts and data definitions, and I can't find info on how these are implemented in SDCC. The particular issues are interrupts in C18 being definied in pragmas and inline code, and a few data structures being declared as packed structs, which SDCC doesn't seem to like. Its been a few years since I got really stuck into some c code, so i'm having to remember alot of the details too.

On a slightly different note, i'm considering rewriting the tcp/ip stack myself, as i could also (maybe) put in ipv6 support at the same time. Is this as silly an idea as I think it is? or is it quite straightforward once i've got some code to handle the ethernet interface?

Regards
Peter

2009/1/28 Kustaa Nyholm <Kustaa.Nyholm@planmeca.com>


>>> tristan.willy@gmail.com 28.1.2009 0:51 >>>
>>  I didn't mean to insult SDCC or spread FUD. I'm simply repeating
>>what's pointed on the SDCC webpage (work-in-progress), documentation
>>(lack of extended instructions, not all tests pass), and various
>>discussions on this mailing list (inline breakage, and your own
>>message about __critical missing).
Good, I like concrete examples of shortcomings, forewarned is
forearmed.

For example:

(from SDCC webpage) work-in-progress: not very usefull info.
This may indicate that the developers thought the compiler is
still not upto standard or that they are simply lacking confidence,
or they wanted to wash their hands.

Lack of extended instructions: nice to know but if the compiler
works just fine without them, then this boils down to sub-optimal
code generation or performance of the generated code issue and
in embedded projects this is often clear cut. Either the code
is fast enough or not.

inlike breakage: again very usefull to know as most of the time
the code write can just circumvent this.

not all tests passed: not very usefull, would have been nice
to know which tests and what are the inferred implications
of not passing all tests.


>> SDCC is a fine compiler and I've
>>used it quite successfully on the 8051 side of things, but it's
fairly
>>clear that the PIC port is not solid yet. Trying to port C code to a
>>new platform without known-working code, guides, or detailed
>>documentation with issues like these makes development less than
>>straight forward.

Agreed but and you maybe right that PIC port is not solid yet, on the
other hand I just worked a year using Blackfin processor and VisualDSP
IDE and the silicon and the VisualDSP (version 5.0!) did not left with
a warm and fuzzy feeling of being solid yet. (And yeah, I've got
80 item long list of concrete issues with the IDE and Analogs silicon
anomaly list speaks for itself.)

>>  FYI, I've using the PIC18 side of SDCC about a 12-18 months ago.
It
>>took quite an effort to get some non-trivial code to work with SDCC;
>>way more effort than what is acceptable in a professional
environment.
I can say the same about the afore mentioned VisualDSP project!

>>This is why I consider users of the PIC port as pioneers.

You maybe right there. Seems like I've picked the right tool. If there
is
an easy way and a hardway, why pick the easy way...

cheers Kusti




On Tue, Jan 27, 2009 at 4:10 AM, Kustaa Nyholm
<Kustaa.Nyholm@planmeca.com> wrote:
> Hi,
>
> being, at least lately, partially responsible for creating the noice
on
> this list
> in regards to PIC18/SDCC I felt I need to comment on this:
>
>>>> tristan.willy@gmail.com 27.1.2009 4:51 >>>
>>>but from what I've read on this mailing list, SDCC has a number of
> PIC18
>>>> shortcomings. You're going to be a bit of a trailblazer here.
>
> Wiile I'm sure there are shortcomings in SDCC as well as in all
other
> compilers weather it is Keil or Gnu gcc or what have you, I'm not
> confortable
> with an off hand remark like this putting down the PIC18 port of
SDCC.
>
> I'been  a long time lurker on this list and it is easy to get the
wrong
> impression
> by casual looking at the mailing since by the very nature of this
sort
> of
> activity we only hear about problems. And very often the problems
turn
> out to be problems somewhere else than in the SDCC and not everyone
> takes the trouble report solved problems, and even fewer report that
> "I've been using SDCC for years without any problems thank you very
> much".
>
> I've used both HC08 and PIC18 ports and while I've had my share of
> problems, none of them have turned out to be even indirectly related
> to SDCC, let alone turned out to be bugs in the compiler.
>
> If there are specific pin pointable problems with any of the ports,
> let us by all means discuss them, but please lets keep from
refraining
> general derogatory comments that contribute nothing but
> spread FUD.
>
>
>
> So there.
>
> br Kusti
>
>
>
------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>



--

- Tristan

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user