gnupic@linuxhacker.org

> 
> On Tuesday 06 May 2003 07:54, Byron A Jeff wrote:

> > > [Actually Craig wrote the innermost quotes. I'm at the second level: BAJ]

> > > I try to be considerate of requests when deciding what to work on.  How
> > > does everyone feel?  Would you rather see a gputils HLL or more work on
> > > gpasm?  Any jal opinions out there?
> >
> > To me it's not even a question of one tool versus the other. gpasm is the
> > flagship tool and it would take precedence over jal in a heartbeat. Jal
> > would definitely be low tool on the totem pole.
> >
> 
> Hay now.  Lets look at what is always at the TOP of a development statck.  
> Thats right, its the HLL.  The lower level stuff may be criticaly important, 
> but its rare that its what user work with.  Just look at how many folks even 
> know what binutls is and yet know GCC, or how many C programmers have every 
> writtien a *.lds linker script, or know what objectdump is.

But that's operating under the presumption that all of the lower level tools
are in place and operating at 100 percent. We know for a fact that all three
main tools in the gputils suite still need work.

Also things are not as cut and dried in the embedded systems world. Lots of
applications still get written in assembly due to performance and/or memory
constraints. The vast majority of introductory code for the PIC is still in
assembly. Not that I think that's the best path necessarily, that's just the
way that it is.

> 
> > [This is BAJ BTW ] 
> > BTW I've seen one dissenting voice against integrating JAL, with the point
> > that by having one HLL in the suite, we'd be creating a defacto HLL choice
> > for development. While that may be true, I feel that we really need to look
> > at expanding beyond the realm of just assembly. I have no problem being
> > language neutral. But I do see a problem not having well integrated
> > (relative to gputils) HLL tools available. And integration is the key. We
> > need a stable of HLL tools that play nice with gpasm, gplink, and gpsim.
> > That's why I'm putting the idea of pulling JAL into the stable.
> >
> 
> You are right.  Jal's syntacs is simpler than C and comes with an active user 
> base (on a Yahoo mailing list) and test code and compiler you could validate 
> the gputils integration against.
> 
>Perhaps Craig is right, and JAL compiler frount end should be started off as a 
> hard fork. You could start by just doing laguage parser frount end, ignoring 
> optimizations, then add optimizations.  One thing would be certain.  It very 
> well could be a complete re-implementation of the language.  The more I think 
> about it the more convinced that it won't be an easy hack.

If that's the case then we probably need to just leave things the way that they
are. I was hoping to leverage the Open Source code of JAL to generate a better
integrated tool without having to invest a significant amount of work to 
achieve that integration. Frankly if we're going to reimplement, then it may
be better to throw those resources into getting SDCC tight enough for daily
use.

I'm looking to tweak, not rewrite. No one has time for that.


> > Maybe the right packaging is to have an HLL extras package that starts with
> > say JAL and SDCC. While physically separate from gputils, it will present
> > a package of HLL tools that has a high level of integration with the
> > gputils suite.
> 
> Whats up with SDCC anyway?  I went to JAL because I couldn't get SDCC / 
> gputils to work last year.

As with all of us, Scott has real work and a real life. He's been swamped and 
SDCC development for the PIC has lagged. 

BTW we can help. If someone has some time and some C expertise, simply ask 
Scott what task needs to be done, check out the code, and work on it.

But it takes time, and effort. And often it isn't time that's simply not
available.

This is one reason I really appreciate all of the work that Scott, Craig, and
Ralf have put into this package. It's also the reason why I would insist on
trying to figure out if JAL can be integrated without a rewrite. Because
no one really has time to do that.

BAJ