gnupic@linuxhacker.org

Byron A Jeff wrote:
>
<snip>
> >
> > - 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.
> 

Yes, a superset would probably work.  I suppose absolute and relocatable
could both be supported.  However, if relocatable is working I am not
sure the absolute mode is needed.

> >
> > - 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 being a little pessimistic.  The first version wouldn't be that
bad.

I also have the linker optimizations in the back of my mind.  Scott and
I have been talking about moving his pcode optimizer into gplink.  If it
happens, it will be some time away.  If it did, it would duplicate
another big chunk of jal code.

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

Not sure about the workarounds.  I always offer them.  Unless it is
something big, I usually fix the bug within a release or two.

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

I don't see that as a problem.  Everyone can still chose from the other
half finished languages out there.

I do understand a diversion of resources argument.

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

It is worth considering.  I think the integration should be possible,
but I doubt all the HLLs will ever be in one easy to use package.

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

No problem.

> BAJ