gnupic@linuxhacker.org

On Mon, May 05, 2003 at 04:15:48PM -0500, Craig Franklin wrote:
> I have been out of town and just started catching up on my email.

Cool beans.

> 
> I am not a jal user.  I saw the GPL message and became interested.  I
> contributed a few things and offered some advice.  My main interest was
> using it to exercise gplink.  I proposed a "relocatable jal".  The
> current developers weren't really interested.  I haven't been involved
> since.
> 
> I did consider forking the source to create a relocatable jal.  In
> general, I hate to do that.  It can cause some real problems for the
> current jal users.  Scott has been putting some time into SDCC, so I
> didn't pursue it further.

Well that's a part of the turbulence of Open Source. I think that if it's
possible to have a strict superset of the current language specification
that it wouldn't be a big issue.

> 
> If jal was added to gputils...
> 
> - The work couldn't start for a month or so.  I am primarily in a gplink
> bug fixing mode.  I am also adding some optimizations to the linker for
> Scott.  I would like a central role in any gputils changes of this
> magnitude.

Timeframe isn't really an issue. We're all swamped with various work. It's
your show, so you call the timeframe.

> 
> - It must generate relocatable objects and use gplink.

Good. That's exactly the integration issue that I'm talking about. I would
hope that it could be made to work seamlessly with all of the other gputil
tools. I think that's going to be the ongoing task.

> 
> - It wouldn't work exactly like the current jal.  New pragmas and
> storage modifiers would have to be added.

Just off the cuff do you think that a strict superset is possible? I don't
have any problem with adding to the language spec. The issue is what happens
when you try to compile a current JAL program in the new setup? Does it fail?
Does it generate something that's not relocatable? So I guess I'm asking
what, if any, failure mode occurs. In a perfect world, it would be none at
all. But as we all know, the world ain't perfect.

> 
> - Most of the code would probably be original, some could be reused. 
> Mainly because much of what jal does is already handled by gputils.

I'm getting red flags and ringing bells over that one. It's funny because one
of the reasons that Wouter open sourced JAL was because he thought that it
would take a total rewrite to get it to do what he wanted it to do.

When you get a chance can you explain this point in more detail? While I can
see that gputils can carry a lot of the load (i.e. it can assemble, link, and
simulate) does that necessarily mean that the existing JAL compiler would have
to be substatively rewritten to get it integrated? Would it not be possible
to simply remove the redundant parts (such as the built in assembler) but
leave the parser and assembly code generator intact?

> 
> I am not against adding a high level language to gputils.  If things
> keep going well, I may have time later this summer.

Craig, this wasn't a request for you do to the job. I hadn't even gotten to
the issue of division of work. I was really wondering aloud whether or not
it is a good idea.


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

> 
> 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 once I finally finish this PhD (summer or bust!) I'll have time, and
possibly even some students, to devote to the gnupic development suite. 
picprg development is still the main tool on my plate. But I hope to be able
to lend a hand to gputils development, testing, and integration.

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.

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.

Thanks for taking the time to add your thoughts to the mix.

BAJ