gnupic: Thread: Re: [gnupic] gputils development

On Thu, Nov 13, 2008 at 4:18 AM, Vaclav Peroutka ####@####.#### wrote:

> > gpsim is ok.
> Yes, ok. I don't use gpsim too much. Maybe somebody can clarify - can I
> simulate the code written in C-language compiled with SDCC ?

Last I heard, you can't step through C lines. That's why gpsim always prints
"FIXME: HLL files are not supported at the moment" on the terminal.

BTW Xiaofan, I think gputils could help with some problems that seem like
they're SDCC-only. For instance, a lot of people hesitate to use C because
of the code bloat, and SDCC doesn't do a ton of optimization compared to the
alternatives, but some link-time optimizations could really cut down on the
bloat.

David

On Fri, Nov 14, 2008 at 4:15 AM, David Barnett ####@####.#### wrote:
> BTW Xiaofan, I think gputils could help with some problems that seem like
> they're SDCC-only. For instance, a lot of people hesitate to use C because
> of the code bloat, and SDCC doesn't do a ton of optimization compared to the
> alternatives, but some link-time optimizations could really cut down on the
> bloat.

That is a good idea. But IMHO Microchip has other ideas about
this topic. They are working on LLVM port. In fact, LLVM 2.4
has experimental PIC16 ports.
http://llvm.org/docs/ReleaseNotes.html

Check out LLVM mailing lists and you will know that several
Microchip employees are working on the PIC16 port.

Xiaofan

On Fri, Nov 14, 2008 at 12:36 AM, Xiaofan Chen ####@####.#### wrote:

> That is a good idea. But IMHO Microchip has other ideas about
> this topic. They are working on LLVM port. In fact, LLVM 2.4
> has experimental PIC16 ports.
> <http://llvm.org/docs/ReleaseNotes.html>

I had noticed that. Link-time optimization is one of the big advantages of
LLVM. I seem to remember some users suggesting that SDCC use LLVM when I
followed their mailing list.

I've been wondering how gputils can take advantage of LLVM. It seems like
the LLVM architecture would be an alternative to most of gputils, minus a
PIC14 backend. But I wonder how much LLVM could help with the limited call
stack and pages/banks on the mid-range PICs. I've always been interested in
offloading runtime work into a smarter toolchain instead of the software
developer.

David

On Fri, Nov 14, 2008 at 4:15 AM, David Barnett ####@####.#### wrote:
> On Thu, Nov 13, 2008 at 4:18 AM, Vaclav Peroutka ####@####.#### wrote:
>
>> > gpsim is ok.
>> Yes, ok. I don't use gpsim too much. Maybe somebody can clarify - can I
>> simulate the code written in C-language compiled with SDCC ?
>
> Last I heard, you can't step through C lines. That's why gpsim always prints
> "FIXME: HLL files are not supported at the moment" on the terminal.

Yeah that is an important missing feature.

I do not use gpsim that much either. But it is quite unique in the
sense that it can simulate a system. MPSIM does not simulate
a system. KTechlab is another interesting one. It would be nice to see
gpsim and Ktechlab getting more matured.

In the Windows world, it seems quite some people are using
Proteus VSM (they have a MPLAB plugin). I have not used it
but it seems to be quite capable (it is even able to simulate
USB function).

Xiaofan

On Thu, Nov 13, 2008 at 5:18 PM, Vaclav Peroutka ####@####.#### wrote:
>> Piklab is not moving.
> I never used it

It is a nice IDE and supported quite some compilers and programmers. It
has also limited support of ICD 2 debugging.
http://piklab.sourceforge.net/index.php


>> pk2cmd works fine.
> That is true. But I really miss chip autodetection mechanism
> similar to Windows' PicKit2 programmer. And I do not know how
> to show revision of the PIC. Maybe nice-to-have: automatically
> show ID and revision of the target PIC every time pk2cmd is run.

Future pk2 from Jeff Post may have features.
On the other hand, you can put your feature request for pk2cmd
in this thread. The developer is very responsive.
http://forum.microchip.com/tm.aspx?m=260540


>> Still no good debugger support.
> That is definitely true. Does ANY debugger for PIC on Linux
> exist (even some bad debugger) ? Support of PicKit2 debugger will be really cool.
>

That is the most difficult task as Microchip does not want
to open the debugging protocol.

Xiaofan