Searching \ for '[PIC]: JAL compiler - Linux and Windows 98' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'JAL compiler - Linux and Windows 98'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: JAL compiler - Linux and Windows 98'
2003\03\18@150238 by John Nall

flavicon
face
This report might be of interest to some.  If not of interest, please
delete. :-)

I downloaded the JAL compiler source from voti.nl and compiled it under
Linux (Red Hat 8.0).  It compiled with no errors.  I then wrote a small
test program in JAL and compiled it with the Linux version, and also
compiled it with the Windows 98 version.

As expected, Windows writes the HEX file with both a CR and LF.   Linux
writes the HEX file with only LF.

However, the Linux version is also putting an extra line in the HEX file,
which is strange because I  compared the two ASM files line for line, and
they are identical.  The two compilers are different versions (Windows is
JAL 00.04-50 and Linux is JAL 00.04-53),  but since they produce the same
ASM file then the HEX files should also be the same (except for the CR/LF
issue).

Since I cannot (yet) use Xwisp and my wisp628 programmer to load the Linux
HEX file, I do not know if it will load and/or function correctly or
not.  Next step is to disassemble the Linux HEX file and see what was put
in there.

So, as I said, this may be of interest to someone.  It was to me.  :-)

John

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\03\18@151708 by erholm (QAC)

flavicon
face
I did a similar test some time ago with JAL 00.04-53, but
on OpenVMS 7.3-1 on an Alpha based server, with the original
DEC-C compiler.

JAL compiled with a bunch of warnings about
some undeclared functions, but nothing severe.

Anyway, the HEX file produced was exactly the same
as the one produced on Windows, as seen with
the DIFFERENCES tool on VMS, at least.

I did not write the test JAL program, but downloaded
some JAL example from Wouters site and also the original
HEX file directly from his site.

Jan-Erik Soderholm



John Nall wrote:

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\03\18@162114 by Byron A Jeff

face picon face
On Tue, Mar 18, 2003 at 03:01:53PM -0500, John Nall wrote:
> This report might be of interest to some.  If not of interest, please
> delete. :-)

Now why would we do that!? ;-)

>
> I downloaded the JAL compiler source from voti.nl and compiled it under
> Linux (Red Hat 8.0).  It compiled with no errors.  I then wrote a small
> test program in JAL and compiled it with the Linux version, and also
> compiled it with the Windows 98 version.

Good test.

>
> As expected, Windows writes the HEX file with both a CR and LF.   Linux
> writes the HEX file with only LF.

As expected.

>
> However, the Linux version is also putting an extra line in the HEX file,
> which is strange because I  compared the two ASM files line for line, and
> they are identical.  The two compilers are different versions (Windows is
> JAL 00.04-50 and Linux is JAL 00.04-53),  but since they produce the same
> ASM file then the HEX files should also be the same (except for the CR/LF
> issue).

Not necessarily. Wouter may have added some line to the hex file that doesn't
change the operation, but humors some loader or another.

>
> Since I cannot (yet) use Xwisp and my wisp628 programmer to load the Linux
> HEX file,

Why not? The wisp628 is serial and I thought that Wouter was now developing
his software in Python.

I'm curious because I may break down and build a Wisp628 one of these days.

> I do not know if it will load and/or function correctly or
> not.

I've had no problems. It really didn't even occur to me to check the hex
file before loading it into my 628.

I've actually spent some time this week working on JAL. I made a one line
patch that allows the libraries to be located in a global spot:

/usr/local/lib/jal

We can get some slightly better Unix/Linux packaging if we packaged the
source/executable along with the libs and a Makefile that will install
everything in the right spot. As a Slackware guy I still use simple .tgz files
but I could certainly see RPMS, .debs, and whatever Gentoo uses for its
Portage system as a useful tool.

The second nut is a bit tougher to crack. Wouter used a couple of different
mechanisms for emulating what the C preprocessor does. One of these is the
"include" statement which is mostly analogous to the C++ "#include" directive
in that it includes the file and will only include it once. All in all not
too bad a system.

However one technique that has popped is the use of the chip specific jpic
library in order to utilize the special features of one chip or another. For
example Vasalie (sp) has created jpic628 and jpic675 for those chips.

So now the conflict occurs because while the compiler won't include the same
file twice, it doesn't have a mechanism to disallow alternatives. And several
of the standard libraries include jpic.

None of the quick and dirty solutions for similar issues in the CPP work. JAL
doesn't have #define and #ifdef for conditional compilation. Simply patching
all of the files that include jpic doesn't work either if you're working in a
multichip (16F877 and 16F628 for example) environment. At this time I really
don't want to have to integrate the CPP into the compiling process because that
means that the Unix and Windows versions will be divergent.

So my tack was to extend the include statement slightly so a programmer could
indicate that the file being included supplants another file (or files).

So I spent about an hour getting down and dirty in jal.c. Wouter has done an
excellent job of organizing what he has been calling a mess. I figured out
how parse_include does the include files and added a loop to process a comma
separated list of extra files. So now an include like:

include jpic628,jpic

will include jpic628 and put both jpic628 and jpic on the already included file
list.

I'm still working out the bugs. Once I do, I'll ask Wouter what he thinks.

>  Next step is to disassemble the Linux HEX file and see what was put
> in there.

I'm pretty sure that it's something harmless. But I'm still interested.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\03\18@172505 by John Nall

flavicon
face
> >Not necessarily. Wouter may have added some line to the hex file that
> doesn't
>change the operation, but humors some loader or another.

Possibly.  I've been bugging him over the last few days, to get some
glitches out of my Wisp628 (cockpit error, as expected) ,and so didn't
figure I should ask him about something like that. :-)

> >> Since I cannot (yet) use Xwisp and my wisp628 programmer to load the Linux
> >> HEX file,
>
> >Why not? The wisp628 is serial and I thought that Wouter was now developing
>his software in Python.

Yup.  Xwisp.py gets no complaints from Python, but barfed when I gave it a
hex file to load.  Wouter has a vast vocabulary of exotic languages to pick
from, but I know C and that is about it.  So have not really been able to
figure out the problem.  (The wisp628, of course, should not care one way
or  the other what OS is accessing it, so I didn't really mean that I
couldn't use it).


> >I'm curious because I may break down and build a Wisp628 one of these days.
>...
> >I've had no problems. It really didn't even occur to me to check the hex
>file before loading it into my 628.

Those two statements seem to be inconsistent. :-)

> >I've actually spent some time this week working on JAL. I made a one line
>patch that allows the libraries to be located in a global spot:
>
>/usr/local/lib/jal

Like to have that patch, if you want to share it.  I just use -slib right now.

> > > Next step is to disassemble the Linux HEX file and see what was put
> > >in there.
>
> >I'm pretty sure that it's something harmless. But I'm still interested.

A cursory glance at it says that it is harmless, because the following line
in the hex file loads at the same address, effectively overlaying it
completely.  But I'd like to know why it is there.  :-)

John

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\03\18@175344 by Byron A Jeff

face picon face
On Tue, Mar 18, 2003 at 05:24:54PM -0500, John Nall wrote:
{Quote hidden}

I wasn't aware that Linux wasn't working with the software. Everything I know
about the wisp628 I've gotten from Mailing lists.

BTW Python is so simple that as a C guy you can probably get in an figure
out whats going on in about 10 minutes.

>
>
> > >I'm curious because I may break down and build a Wisp628 one of these days.
> >...
> > >I've had no problems. It really didn't even occur to me to check the hex
> >file before loading it into my 628.
>
> Those two statements seem to be inconsistent. :-)

I use my Trivial LVP programmer to program 628s:

http://www.finitesite.com/d3jsys

>
> > >I've actually spent some time this week working on JAL. I made a one line
> >patch that allows the libraries to be located in a global spot:
> >
> >/usr/local/lib/jal
>
> Like to have that patch, if you want to share it.  I just use -slib right now.

-------------------------- Cut between the lines -----------------
*** jal.c       Tue Mar 18 17:42:47 2003
--- jal-search.c        Tue Mar 18 17:47:03 2003
***************
*** 12849,12854 ****
--- 12849,12856 ----
       exit( -1 );
    }

+    search_option( "/usr/local/lib/jal" );
+
    /* do everything but simulation */
    prepare_compilation();
    command_line[ 0 ] = '\0';
-------------------------- Cut between the lines -----------------

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\03\18@180207 by

flavicon
face
John Nall wrote:

>> >Why not? The wisp628 is serial and I thought that Wouter was now developing
>>his software in Python.
>
>Yup.  Xwisp.py gets no complaints from Python, but barfed when I gave it a
>hex file to load.

FYI, you might have seen that Rob Hamerling (http://www.robh.nl/) have
a port of Xwisp to C on his home page. Might be a way to make Xwisp
more plattform independent. I'm going to test-built it on my VMS system :-)

Jan-Erik Söderholm.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...