gnupic: Thread: Should JAL be added to the gputils?

Just wondering if maybe we should add JAL to the gnupic lineup?

JAL (http://www.voti.nl/jal) is a high level language PIC compiler. It's
primary focus so far has been the PIC 14 bit family. But there has been some
18FXXXX support added.

Wouter van Ooijen, JAL's author, released the source of the project into the
GPL nearly 6 months ago. It can be downloaded from the website. JAL also 
carries a widely read Yahoo group: http://yahoo.groups.com/group/jallist
and a fairly recently created developers group: 
http://yahoo.groups.com/group/Jal_developers

JAL has an extensive set of libraries to operate a wide variety of devices
such as HD44100 LCDs, 7 segment LED displays, and I2C interfaces. In addition
JAL libraries have a lot of support for PIC internal devices such as hardware
USARTs, A/D converters, timers, and the like.

The simple Pascal like language syntax is fairly easy to pick up too. In 
addition Wouter has written fairly extensive documentation for the language.

In my personal JAL port I've added a couple of small items:

* Default library directory support. Specifically /usr/local/lib/jal is
  autosearched for library files.

* A slightly more extensive upgrade that handles the issue of multiple
  include file inclusion using aliased filenames. JAL was primarily developed
  under windows and as such didn't utilize the C PreProcessor. So include files
  are in fact a part of the language. In addition like C++, include files are
  automagically excluded after the first inclusion. However it breaks down
  if the include file name is aliased. For example JAL has a default include
  file for pin definitions, called jpic.jal. But there are processor specific
  definitions files, say for the PIC 12F675, that has improved routines for
  accessing the parts periperals over the standard jpic.jal. However replacing
  the original include of
   
   include jpic.jal

   with something like

   include jpic_12F675.jal

   will cause failure because several of the internal includes include jpic.jal
   under the presumption that if it's already included, then there's no foul.
   Unfortuately it does fail because after including jpic_12F675.jal, the 
   subsequent include of jpic.jal will happen, causing conflict.

   Of course here's the wonder of Open Source. I hacked in an alias mechanism
   so that any number of include file names can be autoexcluded in a single
   include statement. So I would instead encode the above include as:

   include jpic_12F675.jal,jpic.jal

   which tells the compiler to actually include the first file, and to mark 
   any subsequent files as being included already. So I get the updated 
   definitions, and any subsequent includes of jpic.jal will be skipped.

I'm just thinking that the gputils group may be able to use JAL as a kinder,
gentler intro to PIC programming. A lot of times speed isn't the issue in
getting a job done, but how simply the job can be specified in code.

I do think that JAL would need at the very least an autoconfig file to simplify
installation. Amazingly enough Wouter has the project as a single 13K line C
file. Also I guess that adding some sort of gpsim support would probably be
next on the support list.

Any thoughts?

BAJ

On Sunday 04 May 2003 16:47, Byron A Jeff wrote:
> I'm just thinking that the gputils group may be able to use JAL as a
> kinder, gentler intro to PIC programming. A lot of times speed isn't the
> issue in getting a job done, but how simply the job can be specified in
> code.
>
> I do think that JAL would need at the very least an autoconfig file to
> simplify installation. Amazingly enough Wouter has the project as a single
> 13K line C file. Also I guess that adding some sort of gpsim support would
> probably be next on the support list.
>
> Any thoughts?
>

um,  
http://sourceforge.net/projects/jal

--mgross

On Sun, May 04, 2003 at 05:38:32PM -0700, Mark Gross wrote:
> On Sunday 04 May 2003 16:47, Byron A Jeff wrote:
> > I'm just thinking that the gputils group may be able to use JAL as a
> > kinder, gentler intro to PIC programming. A lot of times speed isn't the
> > issue in getting a job done, but how simply the job can be specified in
> > code.
> >
> > I do think that JAL would need at the very least an autoconfig file to
> > simplify installation. Amazingly enough Wouter has the project as a single
> > 13K line C file. Also I guess that adding some sort of gpsim support would
> > probably be next on the support list.
> >
> > Any thoughts?
> >
> 
> um,  
> http://sourceforge.net/projects/jal

That's progress. I hadn't checked that site in a couple of months. The
release is recent. And I'm quite happy to see that Craig Franklin is on
the JAL team over there as he's one of the primary motivators of gputils.
The split up source and autoconfig is cool too. I guess this is where I'd
have to send my include alias patch.

But it still doesn't address my fundamental question. A significant part
of gputils power is a single package that integrates a set of tools that
work well together. I'm well aware that not everyone will need a high
level language. But I think that it would be quite effective if gputils had
a high level language bundled that worked seamlessly with the linker and
the simulator so that it could be used as a substitute for gpasm.

In fact I somewhat think that having a separate project may cause some
serious syncronization issues down the road.

It just seems like a good idea on the surface. I guess I'm wondering if there
is anything significant that I'm missing.

BAJ

On Sun, May 04, 2003 at 07:47:57PM -0400, Byron A Jeff wrote:
> Also I guess that adding some sort of gpsim support would probably be
> next on the support list.

Actually, there is already support for SDCC-style HLL line number
information. IIRC adding  -rg to the command line will make jal
generate line numbers for gpsim. It's not documented anywhere though.

 / Ralf

On Sun, 4 May 2003 19:47:57 -0400 (EDT)
####@####.#### (Byron A Jeff) wrote:

> Just wondering if maybe we should add JAL to the gnupic lineup?

[..]

> 
> I do think that JAL would need at the very least an autoconfig file to simplify
> installation. Amazingly enough Wouter has the project as a single 13K line C
> file. Also I guess that adding some sort of gpsim support would probably be
> next on the support list.
> 
> Any thoughts?

 I've used JAL in a few small projects and know of some people
 which used JAL to approach the PIC world.

 It seems the current jal CVS has already got under some
 review/split process, so integrating it should be quite easy
 and could be very useful for newcomers.


-- 

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it

On Mon, May 05, 2003 at 06:30:44AM +0200, Ralf Forsberg wrote:
> On Sun, May 04, 2003 at 07:47:57PM -0400, Byron A Jeff wrote:
> > Also I guess that adding some sort of gpsim support would probably be
> > next on the support list.
> 
> Actually, there is already support for SDCC-style HLL line number
> information. IIRC adding  -rg to the command line will make jal
> generate line numbers for gpsim. It's not documented anywhere though.

Cool. But I still haven't heard any opinions on the core ideas. So I'll state 
it again (espcially for you Ralf as one of the active gputils developers):

Do you think it's a good idea to look into integraing JAL into the gputils
suite? If so then what would be the best mechanism for doing so?

BAJ

I have been out of town and just started catching up on my email.

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.

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.

- It must generate relocatable objects and use gplink.

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

- 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 am not against adding a high level language to gputils.  If things
keep going well, I may have time later this summer.

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?

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.

Byron A Jeff wrote:
> 
> On Mon, May 05, 2003 at 06:30:44AM +0200, Ralf Forsberg wrote:
> > On Sun, May 04, 2003 at 07:47:57PM -0400, Byron A Jeff wrote:
> > > Also I guess that adding some sort of gpsim support would probably be
> > > next on the support list.
> >
> > Actually, there is already support for SDCC-style HLL line number
> > information. IIRC adding  -rg to the command line will make jal
> > generate line numbers for gpsim. It's not documented anywhere though.
> 
> Cool. But I still haven't heard any opinions on the core ideas. So I'll state
> it again (espcially for you Ralf as one of the active gputils developers):
> 
> Do you think it's a good idea to look into integraing JAL into the gputils
> suite? If so then what would be the best mechanism for doing so?
> 
> BAJ
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

On Mon, May 05, 2003 at 02:14:17PM -0400, Byron A Jeff wrote:
> On Mon, May 05, 2003 at 06:30:44AM +0200, Ralf Forsberg wrote:
> > On Sun, May 04, 2003 at 07:47:57PM -0400, Byron A Jeff wrote:
> > > Also I guess that adding some sort of gpsim support would probably be
> > > next on the support list.
> > 
> > Actually, there is already support for SDCC-style HLL line number
> > information. IIRC adding  -rg to the command line will make jal
> > generate line numbers for gpsim. It's not documented anywhere though.
> 
> Cool. But I still haven't heard any opinions on the core ideas. So I'll state 
> it again (espcially for you Ralf as one of the active gputils developers):
> 
> Do you think it's a good idea to look into integraing JAL into the gputils
> suite?

Do you mean packaging it together with gpasm and friends?

I don't actually use JAL myself, so I don't really have an opinion.

For gpsim, adding support for gpasm in JAL could be nice, since I 
think you have to reassemble the asm file with gpasm for it to
work with gpsim. gpsim looks for line numbers only when loading 
a cod file.

Does anyone know how active the development of JAL is? I ask since
when I try to compile any file with the cvs on sourceforge it failes
with:
>  error: operator not known for these operands
>  file 'jpic.jal' line 501 char 60
>  :     var byte a at trisa = ( trisa & 0x0F ) | ( ( d & 0x0F ) << 4 )
>  :  -----------------------------------------------------------^^
It has been like that for a long time. It works with Wouter's version.

BTW, the gnupic page should be updated. It says JAL is not open sourced.

 / Ralf

On Mon, May 05, 2003 at 04:15:48PM -0500, Craig Franklin wrote:
> 
> 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.

Maybe we should have a bug-fixing day, or a remote hackathon?  People
would sit down with their favorite MPLAB reference, see how it works
in gpasm versus MPLAB, and post the results with:

0) Is there a difference?
1) Does the difference matter?
2) Does the difference make gpasm better than MPLAB?
3) Does the difference make gpasm worse  than MPLAB?

and optional patches.

Colin

I am always happy to get a bug report.  If you want to sponser a
hackaton, do it. 

The problem isn't knowing were the bugs are.  You only have to run the
testsuite to find them.  I also have an application note test.  It
compiles all the app notes and reports the ones that don't pass.

The problem is the hack that is required to make them work.  Some of
mpasm's features have developed over several years and are not always
consistent with the documentation.  For example, the last time I
checked, #ENDIF was a valid alias for ENDIF, but it could only appear in
column 1. #IFDEF is a valid alias for IFDEF, but can appear anywhere.  I
don't believe either alias is documented.  They are probably legacy
features. Is the different behavior intentional or a bug?

This is just one example.  There are many others.  This one was easy to
fix.  Adding all of these features will turn gpasm into serious
spaghetti code.  In the end, a large effort will be spent and I am not
sure you can argue that gpasm is "better".

I receive very few bug reports.  I am not sure why.  I have read a few
complaints on other lists, but those people never submit bug reports. 
So I have a request.  If you have a feature or bug that you need
resolved, please add it to the trackers on sourceforge.

Colin Kuskie wrote:
> 
> On Mon, May 05, 2003 at 04:15:48PM -0500, Craig Franklin wrote:
> >
> > 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.
> 
> Maybe we should have a bug-fixing day, or a remote hackathon?  People
> would sit down with their favorite MPLAB reference, see how it works
> in gpasm versus MPLAB, and post the results with:
> 
> 0) Is there a difference?
> 1) Does the difference matter?
> 2) Does the difference make gpasm better than MPLAB?
> 3) Does the difference make gpasm worse  than MPLAB?
> 
> and optional patches.
> 
> Colin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####