gnupic@linuxhacker.org

On Tuesday 06 May 2003 07:54, Byron A Jeff wrote:
> > 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.


> > I do get burned out on gpasm from time to time.  It's not bad, but
> > deriving requirements from mpasm is.  I think we are starting to have
> > diminishing returns with the gpasm bug fixes.  We are 95% there.  The
> > last 5% will take BIG work.
>
> A question here: How much of the last 5% have workarounds? As you've
> pointed out it is a question of diminishing returns. I'm really happy to
> see that gplink has taken center stage as of late. It's going to be one of
> the tools that takes the gputils package to the next level.
>


> 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.


> 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.

--mgross