Jalv2 to C
mattschinkel
> The ultimate goal: use the AST to implement a JALV2 input to C output
> translator or 'compiler' which could be targeted to other chips, like
> the 34F, 30F, ARM9.
>
> William
I actually have concerns about this. You can decide weather these
things are good or bad. When I talk about C language, I talk about
SDCC mostly (since it is an open source language).
We would be contributing all of our work to the C world. SDCC does not
have the extensive libraries that we have, well, not in an organized
fashion. I have recently taken a peek at there contributors form/
mailing list. They do not even have proper licensing discussed as we
have with BSD/ZLIB. It has taken us 2 years to get this far with libs,
it will take them zero days to get this far?
Without looking at / maintaining our own libraries, do you think
someone will copy/modify our work, or remove our names from it?
hopefully not.
We will have 2 copies of each library & sample, one may get modified
by a C user. Does this mean the JAL file will be out-dated? How can
the C library be converted to jal?
I think we should convert C to JAL. In my opinion this should be the
first step before we convert JAL to C. Being able to share both ways
will benefit both communities. C has more features, so this may be
tricky.
C to JAL would also allow more types like 34F, 30F, ARM9 as well.
Are we going to have to rename Jallib to Jallib+C ?
I don't think it is fair to ourselves to convert JAL to C and not the
other way around.
Matt.
AlbertF
On Mar 18, 4:37 am, mattschinkel <mattschin...@hotmail.com> wrote:
> I think this can be a jallib topic, since our work will be affected.
>
> > The ultimate goal: use the AST to implement a JALV2 input to C output
> > translator or 'compiler' which could be targeted to other chips, like
> > the 34F, 30F, ARM9.
>
> > William
Why converting to C? I would rather spend the effort on creating a
front-end
for GCC, so JAL can support PIC32, ARM, dsPIC targets. Once you have
the AST
it should be fairly easy to generate the intermediate GCC format
(GENERIC or GIMPLE)
Albert
Mike@watty
It's pretty easy to convert basic non GUI programs that don't make a
lot of library use. So Modula-2, Pascal, C, VB6 and some Java & C# is
easily manually converted.
If it uses GUI or a lot of libraries esp. OS APIs and file operations
an automated C to Jal tool will be like a chocolate teapot.
I worked on the original C++ to C preprocessors. I think C is a
terrible language. It was NOT invented as a high level language but as
a portable abstract assembler to move UNIX software to different cpus
and HW.
So I have no interest in either automated tool C -> Jal (because of
library / API issue and bad C coding practices regarding type casting
and strings) nor JAL to C.
IMO the most worthwhile (only worthwhile) non PIC targets are the
CortexM0, CortexM1 and maybe CortexM3 ARMs. These should be done by
producing Thumb2 assembler, not an intermediate C. The larger or older
ARMs and ARMs for PDAs, Routers, Setboxes, Phones and MID/Netbooks are
best programmed with existing tools, libraries and languages for the
existing OSes.
The higher PICs than 18F4xxx type range are of zero interest,
especially the Microchip 32 bit which are MIPS licence core. ARM
cortex Mx series is the upgrade path. From $1 upwards. I should get my
entry level €5 Cortex M0 today in post :-)
For Cortex M0, M1, M3 I propose a JAL3 that will 100% compile JAL2
code but have extensions that take advantage of having indirection,
minimum 8K RAM, no paging on Flash Program space or RAM space and no
shared banks. "Handy" would be a good alias for Jal3 (Handy to make
JAL produce Thumb2 on ARMs)
Summary. Ignore C unless you have to take notice. My vote is zero
involvement of JAL with C.
My son is doing a C project on 16F877 using Microchip IDE and HiTech-
C. He is not a happy puppy despite all his desktop C and Java
experience on Windows and Linux. The ASM it is producing is rubbish
compared to JAL. He is plagued with bugs in #defines
C relies a lot on Macros and non-macro #defines. This is evil.
Larger projects rely on incomprehensible Make files. This is why good
C IDEs have their own project files too.
We want to avoid any more development of "pragma" in JAL and avoid "C"
contamination. Even some long term official C libraries have evil
gotchas. If you think scanf is input persona of printf you are wrong.
If you think printf is good then you need therapy. Originally C++ and
Java had no printf. C programmers forced the inclusion.
Almost all bugs and security issues in Linux and Windows software is
due to C programming practices unchanged since the late 1970s. Much C+
+ code breaks the real Strustrupp intentions of C++ and is really C
with Class declarations replacing struct declarations.
funlw65
Last night I finished my first "blink a LED" test in SDCC 2.9.7
without destroying your bootloader. Next step (and without this, I
would not take SDCC into consideration) is to convert your USB
libraries (I don't touch the headers in any way) but I'm a little
scared by the task. Anyway, I must start somewhere...
I also successfully tested a modified version of Diolan USB HID
Bootloader from which XTEA encoding part was removed (same memory
space occupied - 2Kb) but this is another story ( I found this version
of bootloader in this project:
http://dangerousprototypes.com/2010/01/29/prototype-usb-infrared-remote-control-receivertransmitter/
)
Vasi(funlw65)
William
>
> I actually have concerns about this. You can decide weather these
> things are good or bad. When I talk about C language, I talk about
> SDCC mostly (since it is an open source language).
>
Hi Matt,
The goal is to make the use of JAL more widespread, by providing a way
to let it run on any cpu, from any chip vendor (like NXP, Atmel,
Xilinx, not just other Microchip) that has an existing C compiler.
The idea was suggested by Wouter, the inventor of JAL, over on the
JALLIST, and it might be better to read his own reasons why he wants
it, than for me to run the risk of mis-quoting him here.
I'm just trying to re-pay him for his original work. I don't know how
much, if any of JALLIB would make sense on the other chips. Very
little I guess.
I don't think anyone would use the generated C code directly-- think
of it as a high-level assembly language. It probably would look ugly.
William
William
>
> Why converting to C? I would rather spend the effort on creating a
> front-end
> for GCC, so JAL can support PIC32, ARM, dsPIC targets. Once you have
> the AST
> it should be fairly easy to generate the intermediate GCC format
> (GENERIC or GIMPLE)
>
Hi Albert,
Thanks for the tip, I will check into it!
William
William
>
> I worked on the original C++ to C preprocessors. I think C is a
> terrible language. It was NOT invented as a high level language but as
> a portable abstract assembler to move UNIX software to different cpus
> and HW.
>
Exactly! 'portable abstract assembler' !
> For Cortex M0, M1, M3 I propose a JAL3 that will 100% compile JAL2
> code but have extensions that take advantage of having indirection,
> minimum 8K RAM, no paging on Flash Program space or RAM space and no
> shared banks. "Handy" would be a good alias for Jal3 (Handy to make
> JAL produce Thumb2 on ARMs)
>
Cool, let me know when you need testers for your JAL3! Seriously!
William
Mike@watty
On Mar 19, 2:22 pm, William <bvwe...@gmail.com> wrote:
> On Mar 18, 3:44 am, "Mike@watty" <wattym...@gmail.com> wrote:
>
>
>
> > I worked on the original C++ to C preprocessors. I think C is a
> > terrible language. It was NOT invented as a high level language but as
> > a portable abstract assembler to move UNIX software to different cpus
> > and HW.
>
> Exactly! 'portable abstract assembler' !
**** in 1976 ****
We have learnt a lot more and Architectures of some CPUs are
different.
Decent language --> P-Code --> specific Assembler.
No C please.
William
>
> **** in 1976 ****
>
> We have learnt a lot more and Architectures of some CPUs are
> different.
>
> Decent language --> P-Code --> specific Assembler.
>
> No C please.
Well, I do plan to look into GCC front-ends, now that Albert has
pointed me in that direction [ thanks again Albert ].
I think we're on the same team here - make JAL more available. And a
little healthy competition is a good thing. Good luck with your JAL3
idea, but my interests go beyond Cortex or any specific chip and
vendor.
Perhaps we could share a common machine-readable JAL grammar? I'm
looking at Antlr for that. There is a snapshot of my efforts in Antlr
here in the file section.
However, I can't resist mentioning that your work in C++ to C
preprocessors must have been later than 1976. Perhaps you meant to
type 1979? :-)
William
Mike@watty
1976 I was doing Fortran as a Student.
1976 the UNIX guys (not me) doing C
1980 I was doing Pascal and Z80 assembler. I got my 1st commercial PCB
made then (I still have one) of my 2K ROM, 2K RAM Z80 4MHz 160mmx
100mm Industrial Controller. It had a National RTC chip and NiCd, Z80
CTC, Z80 PIO and intel 8255 I think. 64 DIN edge connector for I/O and
a piggy back connector beside EPROM for a RAM/ROM expansion board.
1980s serious computer science people realised the severe flaws of C.
Decent Programming languages have unambiguous grammer (C need not
apply). Decent languages and OS mean only the compiler writer ever
manipulates pointers.
1987 was the heyday of C++ to C preprocessors. No "real" C++ compilers
work that way anymore. That is when I was working with C++
preprocessors.
1988 I was implementing Real time Database in C for 8051 in circuit
Emulator.
http://en.wikipedia.org/wiki/Computer_language
Popularity is no measure of Goodness.
"The period from the 1960s to the late 1970s brought the development
of the major language paradigms now in use, though many aspects were
refinements of ideas in the very first Third-generation programming
languages:
* APL introduced array programming and influenced functional
programming.[55]
* PL/I (NPL) was designed in the early 1960s to incorporate the
best ideas from FORTRAN and COBOL.
* In the 1960s, Simula was the first language designed to support
object-oriented programming; in the mid-1970s, Smalltalk followed with
the first "purely" object-oriented language.
* C was developed between 1969 and 1973 as a system programming
language, and remains popular.[56]
* Prolog, designed in 1972, was the first logic programming
language.
* In 1978, ML built a polymorphic type system on top of Lisp,
pioneering statically typed functional programming languages.
Each of these languages spawned an entire family of descendants, and
most modern languages count at least one of them in their ancestry.
The 1960s and 1970s also saw considerable debate over the merits of
structured programming, and whether programming languages should be
designed to support it.[57] Edsger Dijkstra, in a famous 1968 letter
published in the Communications of the ACM, argued that GOTO
statements should be eliminated from all "higher level" programming
languages.[58]
The 1960s and 1970s also saw expansion of techniques that reduced the
footprint of a program as well as improved productivity of the
programmer and user. The card deck for an early 4GL was a lot smaller
for the same functionality expressed in a 3GL deck."
Look up Occam, Modula-2, Ada, Forth, Smalltalk, Oberon and C++ in
Wikipedia
And http://en.wikipedia.org/wiki/CHILL_programming_language (used more
as protocol description as alternative to SDL than as a real
programming language. We re-implemented CHiLL as C, Pascal and my own
schematic based Dataflow language for Z80 called "Hardcore" based on
ideas of Westinghouse "Blockware" in 1985 .. 1987 for C.O. Trunk
Protocol converters.
Java and C# are the only two decent recent attempts at major new
languages and while both avoid some of the C flavoured pitfalls the
Designer didn't want in C++ (AT&T wanted backward compatibility, which
is the greatest ill of C++), they are flawed. Terrible support for
multiprocessor, processes, Realtime processing and verification.
Realtime java is a fudge. Try doing an embedded system or programming
without mono or .net with C#
Ruby, php, python and all the similar are toy languages developed for
scripting web servers and are useless for embedded, realtime or
reliable systems. They have been developed in an adhoc fashion.
Really since the late 1980s progress in quality and correctness of
programming has advanced very little.
William
Don't be bashful, tell us what you think! :-)
I just want JAL to be widely used, maybe you do also.
You have your likes and dislikes, as do I.
Personally, I never liked C++, since a novice could still accidentally
write C by mistake. Java looked technically interesting, but the feud
between Sun and Microsoft left me cold. So, until recently - last
summer, when I began working in Python, C has served me well.
For embedded systems, I've mostly used C, and some JAL, and lots of
assembler when required. It is rare that I get to pick and choose.
William
ps: I did Fortran as student in '76 also. Had a dream job beta-testing
VAX/VMS in late '78 thru '80. Did my first C code around 1980- DECUS C
and Small-C. Never looked back.
Mike@watty
On Mar 19, 5:42 pm, William <bvwe...@gmail.com> wrote:
> Hi Mike,
>
> Don't be bashful, tell us what you think! :-)
>
> I just want JAL to be widely used, maybe you do also.
>
> You have your likes and dislikes, as do I.
>
> Personally, I never liked C++, since a novice could still accidentally
> write C by mistake.
The biggest mistake was AT&T insistence on backward compatibility.
My Wife was PAID to write Fortran after she graduated. She was taught
by Prof Hoare and she taught me how to program "properly".
You have to hyper focus with C, and work daily with same libraries and
platform. Then you can get the job done. However C programming is
responsible for most of the security issues of PC.
Mike@watty
My recent C was Geode based Linux SBC in handheld tester and PXA255
ARM.
And translating code to JAL for my CatPad. I'm at 10,098 lines of JAL
and rising.. :-(
85% of 32Kbytes used ... Oh Dear.
Kyle
On Fri, 19 Mar 2010 15:16:01 -0700 (PDT), Mike@watty wrote
>
> You have to hyper focus with C, and work daily with same libraries
> and platform. Then you can get the job done.
I don't think this is true -- I work on dozens of disparate platforms with the
same libraries, and several with totally different libraries & seem to get the
job done just fine.
> However C programming
> is responsible for most of the security issues of PC.
No, programmers are responsible for *all* security issues. Bad programmers can
be insecure in any language.
--kyle
Mike@watty
On Mar 20, 5:59 pm, "Kyle" <googlen...@videovideo.com> wrote:
> Greetings,
>
I was generalising..
However it's true that no language can help a Bad programmer write
good programmes and that a Good programmer can write good programs in
any language.
Kyle, you're hardly representative, you're probably in the top percent
of good programmers :-)
I'm a designer and comms engineer. I can design and write from
scratch. I'm hopeless at modifying other people's large projects or
debugging my own if it doesn't just work! :D
Joep Suijs
> Well, I do plan to look into GCC front-ends, now that Albert has
> pointed me in that direction [ thanks again Albert ].
Any progress on this?
I have given this some thought. I expect a conversion from JAL to C
can be done, just like JAL to GIMPLE. However, the second one needs to
be complete, so you need device files for every platform. If you use
C, you can probably use the C header files. Downside is that while
converting, you must assume that all unknown variables et al do exist
in C and, in addition to this, need to be case-sensitive.
But the advantage is you can port it to a new platform with little effort!
I also had a brief look at the JAL compiler source, but did not find
an easy way to use it convert a source file into a list of tokens...
Joep
William
>
> Any progress on this?
>
> I have given this some thought. I expect a conversion from JAL to C
> can be done, just like JAL to GIMPLE. However, the second one needs to
> be complete, so you need device files for every platform. If you use
> C, you can probably use the C header files. Downside is that while
> converting, you must assume that all unknown variables et al do exist
> in C and, in addition to this, need to be case-sensitive.
> But the advantage is you can port it to a new platform with little effort!
>
Greetings Joep,
I'm glad you're thinking about the project. Your summary matches my
original understanding of what Wouter was asking for.
I haven't done anything further, yet, other than look at GCC front-end
docs a little. Seems cool, but huge learning curve. Seems harder than
Antlr, but it surely would be powerful to leverage GCC back-ends.
Previously, I did a fair amount of work with 'Antlr', which was going
along smoothly I thought - I just haven't had much time recently to
work on it. My thought with Antlr was two-fold:
1) use Antlr to define a formal 'grammar' for JALV2. By formal I mean
machine-readable -- a real JALV2 parser (no semantic handling though)
then
2) use Antlr, and the grammar developed in step #1, to add ASTs.
other notes:
3) you can choose Java, C, or Python as output from Antlr. I was using
Python, but if someone preferred C, that would be fine too.
My snapshot of the Antlr work for JAL is in this google group file
area-- jal_grammar_snapshot.zip. Note carefully the comments in the
code-- it explains exactly which version of Antlr I chose, in order to
match up with the Python Antlr run-time. Apparently the Python output
from Antlr lags behind the Java efforts. It is possible that by now,
there is a newer version of Python Antlr run-time available.
William
Joep Suijs
2010/4/7 William <bvw...@gmail.com>:
> I haven't done anything further, yet, other than look at GCC front-end
> docs a little. Seems cool, but huge learning curve. Seems harder than
> Antlr, but it surely would be powerful to leverage GCC back-ends.
The leverage is obvious. But what is the advantage of generating
intermediate code over C? With C
- you can skip the learning curve
- you can (but not have to) take advantage of the include files.
- still have the leverage of the back ends
- it is probably easier to debug (assuming the c-front end gives
better error messages than the back end and the c-file is more
readable).
This does of course require that jal can be translated into pretty
efficient C code. I have been thinking about this and did not come
across a construct which seems too hard. pseudo variables passed to
pointers is probably the most complex one.
> Previously, I did a fair amount of work with 'Antlr', which was going
> along smoothly I thought - I just haven't had much time recently to
> work on it. My thought with Antlr was two-fold:
>
> 1) use Antlr to define a formal 'grammar' for JALV2. By formal I mean
> machine-readable -- a real JALV2 parser (no semantic handling though)
> then
> 2) use Antlr, and the grammar developed in step #1, to add ASTs.
>
I am not really into language design (yet ;) but build a few parses
(by hand) of complex configuration files, that output a list of
'atoms' - all elements in the encountered sequence with all irrelevant
info (like comment, white spaces) removed and worked from there on.
Maybe your antlr is useful to generate the first step and create such
a list (or even a more advanced one)
> 3) you can choose Java, C, or Python as output from Antlr. I was using
> Python, but if someone preferred C, that would be fine too.
I tried Python a few times but did not get to speed... So Perl or C
for me please...
> My snapshot of the Antlr work for JAL is in this google group file
> area-- jal_grammar_snapshot.zip. Note carefully the comments in the
> code-- it explains exactly which version of Antlr I chose, in order to
> match up with the Python Antlr run-time. Apparently the Python output
> from Antlr lags behind the Java efforts. It is possible that by now,
> there is a newer version of Python Antlr run-time available.
I intend to finish some of my projects before start major work on new
one's, but this is definitely worth looking into!
Joep
William
>
> The leverage is obvious. But what is the advantage of generating
> intermediate code over C? With C
> - you can skip the learning curve
> - you can (but not have to) take advantage of the include files.
> - still have the leverage of the back ends
> - it is probably easier to debug (assuming the c-front end gives
> better error messages than the back end and the c-file is more
> readable).
>
Your arguments above sound very convincing to me. Perhaps Albert will
chime in about why the GCC approach is better.
> I am not really into language design (yet ;) but build a few parses
> (by hand) of complex configuration files, that output a list of
> 'atoms' - all elements in the encountered sequence with all irrelevant
> info (like comment, white spaces) removed and worked from there on.
> Maybe your antlr is useful to generate the first step and create such
> a list (or even a more advanced one)
Yes, Antlr can handle all of the above and more. Antlr is roughly
equivalent to Yacc and Lex, or Bison and Flex.
Note: We would only have to run Antlr itself once, until a new JAL
language feature was added (grammar changes).
> I tried Python a few times but did not get to speed... So Perl or C
> for me please...
>
I don't mind using C, but you really should give Python another
try. :-)
> I intend to finish some of my projects before start major work on new
> one's, but this is definitely worth looking into!
Good, I'll try and work on a C version (instead of Python) of my Antlr
'snapshot' and also include a little of the output from running all of
JALLIB thru it. It is amazing how much of JALLIB is already being
parsed corrected.
We can actually do both C and Python for awhile and maybe you'll come
to like Python.
William
Mike@watty
On Apr 7, 1:19 pm, William <bvwe...@gmail.com> wrote:
>
> We can actually do both C and Python for awhile and maybe you'll come
> to like Python.
>
> William
I'm still confused as to why this is got anything to do with Jallib or
jal.
How many 100,000 line programs are there in JAL that need to be ported
to C?
How many programs or libraries in JAL need ported to C?
If it works on 18F why port it to any other chip?
If you really need an ARM, x86 or MIPS (PIC32) (forget the other
processors mostly and possibly MIPS too) and not an 18F, it's likely
you need an OS too. I see little value in porting existing JAL code.
I'd see some value in an enhanced JAL, aka JAL3/Handy that has strong
types, sets, enums, records, objects (but no pointers, thanks!), user
defined types, Modules/Block with export and global options on
declarations etc. If it 100% accepts current JAL code.
Translated code is a terrible basis for a new project, esp. to C where
there is no shortage of Libraries for ARM, MIPS (PIC32) and x86.
I've looked at PIC16 C compilers compared with JAL. There is no reason
whatsover you would use C on 16F and 18F if you have a Jal programmer
and compiler.
Of course maybe I have totally misunderstood what the purpose of this
is.
funlw65
"Of course maybe I have totally misunderstood what the purpose of this
is. "
Using JAL language (not C) for other microcontrollers than Microchip?
Starting form the premise that C is a portable Assembler?
Vasi(funlw65)
Joep Suijs
2010/4/7 Mike@watty <watt...@gmail.com>:
>
>
>> We can actually do both C and Python for awhile and maybe you'll come
>> to like Python.
Would it take much effort to generate a c-output? If so, I'd like to
receive it and take a look.
> I'm still confused as to why this is got anything to do with Jallib or
> jal.
It would allow you to write jal programs and run them on any system
with a c-compliler. I'd expec you'd like this - more jal and less c ;)
> If it works on 18F why port it to any other chip?
Why would you use JAL for 18F while there is a good C compiler? It is
on 16F chips that JAL provides real added value, since afaik JAL has
better quality than the C compilers.
> If you really need an ARM, x86 or MIPS (PIC32) (forget the other
> processors mostly and possibly MIPS too) and not an 18F, it's likely
> you need an OS too. I see little value in porting existing JAL code.
I don't think this is universally true - many of those chips don't
have the memory or processing power for a real os, but that's besided
the issue. Like this you can use JAL to write programs for operating
systems too.
> Translated code is a terrible basis for a new project, esp. to C where
> there is no shortage of Libraries for ARM, MIPS (PIC32) and x86.
It's not a basis for a project, C is used as portable assembler ;)
> I've looked at PIC16 C compilers compared with JAL. There is no reason
> whatsover you would use C on 16F and 18F if you have a Jal programmer
> and compiler.
Well... C has structures, enums, pointers (so you can have objects). I
know you'll reply 'C is evil', but it provides many powerfull features
you'd like to have in JAL...
> Of course maybe I have totally misunderstood what the purpose of this
> is.
As you may have deduced, I would never have used JAL if there was a
good C compiler for 16f back in 2003 and would be seriously tempted to
switch if there was one now.
For me, this is hobby, which is the purpose on it's own. I am not
interessted in the jal-to-c converter as the result, but in the
creation of such a converter.
Joep
Mike@watty
On Apr 7, 2:57 pm, funlw65 <funl...@gmail.com> wrote:
> Mike wrote:
>
> "Of course maybe I have totally misunderstood what the purpose of this
> is. "
>
> Using JAL language (not C) for other microcontrollers than Microchip?
> Starting form the premise that C is a portable Assembler?
>
> Vasi(funlw65)
Only a useful portable assembler 20 years ago.
If you had a bigger JAL, a dedicated JAL to Thumb/Thumb2 compiler is
the way to go. Compiler and language design has moved on since then.
Yes the early C++ I worked on used a C backend. No decent C++, Java or
C# compiler today does.
Better to put the effort into an Enhanced JAL + Thumb Instruction set
output.
William
>
Mike,
Thanks for your input. I think you've made your disapproval of the
project very clear, and so perhaps we can just agree to disagree?
I welcome any competition to:
1) provide a grammar of JAL. A 'BNF' if you will.
2) provide any means of running JAL on processors besides Microchip.
William
Mike@watty
I'm 100% support of (1) and 100% of (2) other than the effort of
translation to C. -ANY- is too broad.
I will do a grammar of JAL, though Kyle is best placed. Certainly it
will need his confirmation of correctness.
William
>
> Would it take much effort to generate a c-output? If so, I'd like to
> receive it and take a look.
>
> interessted in the jal-to-c converter as the result, but in the
> creation of such a converter.
>
Joep,
Thanks for your interest. I'll find some time and work on a version of
Antlr that generates C instead of Python, and upload a new snapshot so
you can take a look.
William
William
>
> I will do a grammar of JAL, though Kyle is best placed. Certainly it
> will need his confirmation of correctness.
If you don't mind, please take a look at Antlr -- it is just a single
JAR file. :-)
And you can find my attempt at JAL grammar in the snapshot (files area
for this group), in the Antlr syntax. It has nothing to do with C
(yet). ;-)
Thank you,
William
Joep Suijs
I managed to get your grammar snapshot running, but it does not seem
to understand my code. My program is:
var byte aa = 0
procedure aap(byte in bb) is
aa = aa + 1
end procedure
and the output is below. It does not seem to understand my program. I
do like the specific disignation as line 5:4, but it does not help me
to understand what's wrong...
Joep
setting up parser
calling parser
line 5:4 mismatched character u'p' expecting 'i'
var byte aa = 0
line 3:19 no viable alternative at input u'in'
<error: procedure aap(byte in bb) is>
aa = aa + 1
line 0:-1 mismatched input '<EOF>' expecting '='
<mismatched token: <EOF>, resync=rocedure>
back from parser
dumping our parser/tree nodes
var
byte
aa
=
0
<error: procedure aap(byte in bb) is>
aa
=
aa
+
1
<mismatched token: <EOF>, resync=rocedure>
done with parser/tree nodes
2010/4/7 William <bvw...@gmail.com>:
> --
> You received this message because you are subscribed to the Google Groups "jallib" group.
> To post to this group, send email to jal...@googlegroups.com.
> To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
>
>
William
>
> I managed to get your grammar snapshot running, but it does not seem
> to understand my code. My program is:
> var byte aa = 0
>
> procedure aap(byte in bb) is
> aa = aa + 1
> end procedure
>
> and the output is below. It does not seem to understand my program. I
> do like the specific disignation as line 5:4, but it does not help me
> to understand what's wrong...
>
Hi Joep,
Thanks for trying it out. Sorry, obviously my 'snapshot' isn't so
great. I'll work on it.
But what it is complaining about is 'procedure'. It is choking on the
first letter-- 'p'. Note at the end it says 'resync=rocedure'.
Perhaps you can track down what I did wrong, before I have a chance to
look at it.
William
mattschinkel
to make our code 100% in JALv2, then run a compiler that will make our
code work on SDCC?
How will device files be used? will the device files be converted to
JALv2 so I can read them and include them?
Matt.
William
>
> I managed to get your grammar snapshot running, but it does not seem
> to understand my code. My program is:
> var byte aa = 0
>
> procedure aap(byte in bb) is
> aa = aa + 1
> end procedure
>
Greetings Joep,
Thank you for your test. I've fixed some problems and uploaded a new
snapshot here in the file area. There is still lots more to do, but
at least your example should work now.
William
William
Hi Matt,
You've got some great questions there. I don't have the answers yet.
Right now I'm focusing on the grammar.
William
mattschinkel
C code (in the final product), although it will be there and possibly
cause inefficient ASM.
Matt.
Joep Suijs
It does work now and with your explanation and the syntax diagram, it
becomes fun to play with this :) I like these kind of puzzels!
And indeed, there is probably much work to do to get all code of
jallib parsed without errors. Did you think about case-sensetivity
yet? And about actual execute include while you are parsing?
I adapted proc_def so it supports no '()", and just '()' without
params. Also, statement is optional (it is allowed to create a
procedure with empty body). The new code is:
proc_def : 'procedure' IDENTIFIER ( '(' ( proc_parm (',' proc_parm)*
)? ')' )? 'is'
statement*
'end' 'procedure'
;
If you think it is okay, a similar change to function is apporiate
(which also needs the return bit).
Is this (mailing you the changed code) a convenient way for feedback?
Or maybe put it under svn?
Joep
William
>
> It does work now and with your explanation and the syntax diagram, it
> becomes fun to play with this :) I like these kind of puzzels!
Great, I am glad to have your interest and help. I am a total
beginner with Antlr. I have perhaps 3 or 4 evenings worth of
'experience'. Soon, you'll be the expert I am sure.
>
> And indeed, there is probably much work to do to get all code of
> jallib parsed without errors. Did you think about case-sensetivity
> yet? And about actual execute include while you are parsing?
>
I haven't looked into processing include statements yet with Antlr. I
hope it won't be too hard. But at the moment I just was trying to see
how far we could get with the grammar itself. So I cheated, and wrote
a little pre-processor in Python to expand all of the includes and put
into a single, large, jal file for testing.
About case-sensitivity-- my two cents - not to worry right now -- in
the worst case, such errors will be caught further down the process by
the C compiler.
> I adapted proc_def so it supports no '()", and just '()' without
> params. Also, statement is optional (it is allowed to create a
> procedure with empty body). The new code is:
>
> proc_def : 'procedure' IDENTIFIER ( '(' ( proc_parm (',' proc_parm)*
> )? ')' )? 'is'
> statement*
> 'end' 'procedure'
> ;
>
> If you think it is okay, a similar change to function is apporiate
> (which also needs the return bit).
>
Nice improvements -- keep going -- make any changes you think are
good. I'll help out as time permits.
> Is this (mailing you the changed code) a convenient way for feedback?
> Or maybe put it under svn?
>
Do whatever you think is best-- if our project is 'welcome' here, that
is terrific and we can use SVN here. If not, we can find a new home
somewhere else.
Thank you!
William
ps: are you OK with Python for now? If not, it is only 2 or 3
statements near the top of the grammar file to switch to a different
output language.
vasile surducan
Joep Suijs
2010/4/8 William <bvw...@gmail.com>:
> I am a total
> beginner with Antlr. I have perhaps 3 or 4 evenings worth of
> 'experience'.
This means you are still 2.5 to 3.5 evenings ahead ;)
> About case-sensitivity-- my two cents - not to worry right now -- in
> the worst case, such errors will be caught further down the process by
> the C compiler.
Although JSG does not permit 'IF', JAl does and antlr does not for
now. But that is not the main issue right now.
> Nice improvements -- keep going -- make any changes you think are
> good.
I just hoped they are actual improvements...
>
>> Is this (mailing you the changed code) a convenient way for feedback?
>> Or maybe put it under svn?
>>
>
> Do whatever you think is best-- if our project is 'welcome' here, that
> is terrific and we can use SVN here. If not, we can find a new home
> somewhere else.
*** Anybody objects if we put a directory for this jal grammar project
on jallib SVN? ***
> are you OK with Python for now? If not, it is only 2 or 3
> statements near the top of the grammar file to switch to a different
> output language.
I can scribble a bit in Python and you scrips help me out.
Part of the gui is not working yet and I probably have to install java
sdk. I'll focus on this and expect this will provide the functionality
needed to work on the grammar. And we have probably a long way before
the next step...
Joep
Joep Suijs
2010/4/8 vasile surducan <vsur...@gmail.com>:
> ARM (extended to DSP) and FPGA. For the FPGA translation should be from Jal
> to Verilog or VHDL.
VHDL is like Python for me - I've put in to little effort to understand...
> For ARM, a translation from Jal to C, then a compilation under C (as I have
> understood is planned) imply a good knowledge of C even for the Jal user...
> so once C is well known why to bother with this weird combination?
For me this is an experiment to see what it takes to translate jal
into C. If this works, C is and intermediate language where you don't
need extensive knowledge of.
Like you, I don't see much added value of programming parts in C and
parts in JAL. And personaly - if a system has a proper C compiler, I'd
prefere that over JAL...
> Maybe will be much easy to define an ARM family and try to generate the
> output code directly for that one?
Sounds like a nice project too and I am convinced it will generate
better code than the path via C.
I'm just like a young dog: I see something that looks interesting and
get involved. For now this is the grammar and the 'dot at the horizon'
is the translator from JAL to C. We might not get at that specific
point, but as long we have fun on the way it's okay with me. And maybe
it produce something usefull, like a JAL grammar definition in antlr,
that can be used for your JAL-to-ARM compiler.
> In that way, generic libraries conversion should be easier?
What do you mean with generic libraries conversion?
Joep
funlw65
favorite for experienced JAL users/developers?
Vasi(funlw65)
On Apr 8, 3:23 pm, vasile surducan <vsurdu...@gmail.com> wrote:
> Well, at the beginning I was very enthusiastic about this idea, but
> re-reading now the topic
> I'm confused. I have to admit that Mike has (unfortunately) some truth.
> Two types of programmable devices are more interesting for me than PIC
> microcontrollers:
> ARM (extended to DSP) and FPGA. For the FPGA translation should be from Jal
> to Verilog or VHDL.
> For ARM, a translation from Jal to C, then a compilation under C (as I have
> understood is planned)
> imply a good knowledge of C even for the Jal user... so once C is well known
> why to bother with this
> weird combination?
>
> Maybe will be much easy to define an ARM family and try to generate the
> output code directly for that one?
> In that way, generic libraries conversion should be easier?
>
> Vasile
>
> > jallib+un...@googlegroups.com<jallib%2Bunsu...@googlegroups.com>
William
> ARM (extended to DSP) and FPGA. For the FPGA translation should be from Jal
> to Verilog or VHDL.
Greetings Vasile,
Thanks for giving the project some thought and for your interest and
questions.
FPGA -- Interesting and perhaps doable. Right now, the focus is on a
grammar and parser for the input. Output comes later. :-) But just
curious, why not use FPGA with soft or hard support for C, for
instance microblaze or nios?
> For ARM, a translation from Jal to C, then a compilation under C (as I have
> understood is planned)
> imply a good knowledge of C even for the Jal user... so once C is well known
> why to bother with this
> weird combination?
>
Good question, I can only assume Wouter has a good reason, since he
was asking for something like this. However, I think the person
providing support for a new chip may indeed need a good understanding
of C, but perhaps the end-user would not need C so much. Time will
tell.
> Maybe will be much easy to define an ARM family and try to generate the
> output code directly for that one?
> In that way, generic libraries conversion should be easier?
Maybe so, and no reason we can't try such an approach-- hopefully we
can share the same input grammar and parser, and provide multiple
different targets. Whichever one(s) becomes popular, we can choose
it. The others may fall into disuse/neglect.
William
Joep Suijs
I started with the parser and 16f877a.jal as input and it fails at the
first '(' on the line:
_PORTA_shadow = (_PORTA_shadow & 0xF0) | (x & 0x0F)
It looks like parenthesis are not supported and when I tried to add
them, I got a message telling it required backtracking to be enabled.
I think this has to due with operator hierarchy is implemented into
the parser. Anybody has a view on this? Is there a small fix possible?
Should we maintain the operator hierarchy? Would leaving this help?
I'll dig into this, but please give me some direction if you can.
Joep
William
> first '(' on the line:
>
> _PORTA_shadow = (_PORTA_shadow & 0xF0) | (x & 0x0F)
>
Joep,
I'm not sure I understand your question, but that is probably because
you are already deeper into Antlr than I ever was. I guess I'd go
look at the C grammar for ideas?
William
Joep Suijs
> I'm not sure I understand your question, but that is probably because
> you are already deeper into Antlr than I ever was.
I'm afraid it's because I don't realy understand the problem...
Anyway, I made some progress and the device file is parsed without errors :)
There is still a lot of cleanup to do and it is not complete yet. At
least pragmas (and probably more) are not processed properly...
Joep
William
> Anyway, I made some progress and the device file is parsed without errors :)
>
Very cool! I hope to be able to take it for a 'test drive' soon. I
don't yet grasp the LL(*) versus LL(k) stuff. Should be a fun ride
though.
William
William
I'm found that I generally re-write programs at least 3 times before I
begin to be satisfied with an approach. So-- feel free to rewrite any
of the grammar as you see fit.
Also, next time you're in the neighborhood, feel free to add the usual
JALLIB boiler-plate and your name to the author's list.
Thank you for your help!
William
Joep Suijs
The good news is the parser can read the 16f877 device file, process &
dump it and the output is almost compilable.
The 'almost' is the compication:
include chipdef_jallib
pragma target chip 16f877a
The parameters of the two above do not fall into a proper lex
category. For include this example does, but it could have a '/'
(which can be handled) and could start with a number. And that's also
the issue with target chip.
The general rule of the lex analyser is: if it starts with a letter,
it is an identifier. If it starts with a number, it is an constant. So
by the time it reaches the parser, these parameters are already
converted into more then one token. For now, the parser accepts this
and the next level of code has to deal with this, but this is a bit of
a hack. Don't know if this is my limited knowledge of altlr or a quirk
in the JAL language...
Something else is the result of the parser: it seems to provide a
'flat tree' with 5252 nodes while I would expect to find the knowledge
on the structure provided by the grammar, so a tree and (also) encoded
tokens. I'll dig into this, but any advice is appreciated!
Joep
2010/4/10 William <bvw...@gmail.com>:
William
>
> The good news is the parser can read the 16f877 device file, process &
> dump it and the output is almost compilable.
>
That is great news!
> The general rule of the lex analyser is: if it starts with a letter,
> it is an identifier. If it starts with a number, it is an constant. So
> by the time it reaches the parser, these parameters are already
> converted into more then one token. For now, the parser accepts this
> and the next level of code has to deal with this, but this is a bit of
> a hack. Don't know if this is my limited knowledge of altlr or a quirk
> in the JAL language...
I ran into this also, I don't recall whether in Antlr or perhaps one
of the other parsing libraries I tried, before Antlr. I see it as a
sort of quirk of JAL, but there will be many others, so don't worry
about hacks-- right now we are just trying to deal with syntax--
later we will work on semantics. I recommend just keep moving forward
-- Try to get some of the 'blink the led' samples from JALLIB to run
all the way through.
>
> Something else is the result of the parser: it seems to provide a
> 'flat tree' with 5252 nodes while I would expect to find the knowledge
> on the structure provided by the grammar, so a tree and (also) encoded
> tokens.
>
Right, the multi-level structured tree is one of the main advantages
of Antrl (in addition to Python output, but you'll figure that out
eventually I hope. :-) )
I am not sure, but I think we'll have to add some more statements
mixed in with the grammar to accomplish the tree structure.
Personally I was thinking to wait until we have all of the syntax done
correctly, since the extra code makes the grammar harder to read and
edit. But it is quite possible that I am confused about all of this,
so go ahead. Have you looked at some of the small grammar examples?
I know it can be a little confusing to sort out the old 'obsolete'
Antlr examples for the more recent ones. Scott Stanchfield (javadude)
has some nice, fairly recent Antlr tutorials: http://javadude.com/articles/antlr3xtut/
By the way, here are my Antrl bookmarks, in case you're interested:
http://delicious.com/ab4yd10/antlr
Thank you!
William
William
Since you prefer working in C, would it be convenient for you to add
your C code test driver harness to SVN? I can invent my own, but I'm
lazy. :-)
Also, did you intend to put the Antlr jar file in SVN, and also the
output from running Antrl -- the tokens, lexer, and parser for Python
output? That is fine by me, just checking to be sure.
Thank you,
William
Mike@watty
Until a separate BNF or other suitable grammar is defined and gets
kyle agreement, I can't see the value of Antrl.
How do you know it's even capable of parsing JAL?
What will you do about name munging? Perhaps the rules of scope in C
and JAL are not the same (they should NOT be). Will you prefix each
name automatically with it's parent scope?
Blocks create anonymous scope. You need a naming scheme for each block
scope. AFAIK C has no equivalent scope. There is NO problem exporting
EVERYTHING as global scope in C, as long as the names are adjusted
first and the C code is not for humans but only for a compiler.
What if Kyle adopts some of the current suggestions (that are easy to
implement and will work even on 10F) for Block scope enhancement?
The only thing though for certain I heard is "coming soon" though is
literal string constants in expressions/parameters rather than
needing a separate const statement.
I recommend at least reading
Writing Interactive Compilers and Interpreters (P. Brown)
Programming :Language Translation (P D Terry)
Terry explains the limitations of direct decent and LL parsing
See also http://www.devincook.com/GOLDParser/about/why-use-gold.htm
However real computer scientists will point out that Preprocessing /
Translating to C was depreciated over 20 years ago.
Mike@watty
Given the range of languages / grammars already on Gold compared to
Antlr and the range of development languages, You should really check
out Gold for this, even if you stick with C as output:
http://www.devincook.com/GOLDParser/about/comparison-parsers.htm
Overview
The GOLD Parsing System is designed to aid in the development of
compilers, interpreters and translators while supporting multiple
programming languages. To accomplish this goal, the system takes
advantage of the LALR and DFA algorithms. Both of these can be
implemented with simple state transition graphs. As a result, it is
very easy to write the algorithms in different programming language
since the logic simply looks up a value in a table and then acts
accordingly. The creation of these tables is where all the "thinking"
takes place.
The system is composed of two different components, the "Builder" and
the "Engine", and the a file that is stores table information. The
"Builder" constructs the parse tables. The "Engine" uses the tables.
The Components
The Builder
The Builder is used to read a source grammar written in the GOLD Meta-
Language, produce the LALR and DFA parse tables, and, finally, save
this information to Compiled Grammar Table file.
The Builder Application runs on the Windows 32-bit operating systems
which include, but are not limited to, Windows 9x, Windows NT and
Windows XP. The application also contains a number of features which
could have been implemented as different programs. Each feature was
included to create an easy-to-use integrated development environment.
These include the ability to create skeleton programs and the ability
to interactively test a grammar.
There is also a command-line version of the Builder. In the future,
the Builder may be ported to different operating systems such as UNIX,
Linux, and Mac-OS.
Compiled Grammar Table File
The Compiled Grammar Table file is used to store table information
generated by the Builder.
The Engine
The Engine component performs the actual parsing. The Engine can be
developed in any programming language necessary. Since all the complex
work was already performed the Builder, the Engine simply needs to
read the Compiled Grammar Table file and implement the LALR and DFA
automatas.
As different implementations of the Engine are created for different
programming languages, the approach and design will vary. Since
different programming languages use different approaches to designing
programs, each implementation of the Engine will be a little bit
different. As a result, an implementation of the Engine written for
Visual Basic 6 will differ greatly from one written for ANSI C.
Due to the work of kind and generous contributors, there are numerous
Engines at your disposal. Please visit the Engine Download page for
some more information.
Joep Suijs
2010/4/11 William <bvw...@gmail.com>:
> Since you prefer working in C, would it be convenient for you to add
> your C code test driver harness to SVN? I can invent my own, but I'm
> lazy. :-)
No problem, but this is based on antlr3.2. Are you okay with that?
> Also, did you intend to put the Antlr jar file in SVN, and also the
> output from running Antrl -- the tokens, lexer, and parser for Python
> output? That is fine by me, just checking to be sure.
This makes it possible for anybody to compile it or even give it a try
without a compile.
The next step towards a blinking example is creating one big file. You
said you have a Python program for this. Can you add this to svn
(grammar\tools) ?
Joep
William
>
> No problem, but this is based on antlr3.2. Are you okay with that?
Sure, going with the latest is fine with me.
> This makes it possible for anybody to compile it or even give it a try
> without a compile.
I like the idea fine, but I don't see how, since those output files
are already obsolete, aren't they? But if you intend to keep those
files updated, that sounds great. I'd hate for folks to try and take
it for a test drive, only to find it broken or not working. (Which is
what I did to you, still sorry about that).
>
> The next step towards a blinking example is creating one big file. You
> said you have a Python program for this. Can you add this to svn
> (grammar\tools) ?
>
I think you already checked it in, didn't you? But for blinking LED
sample, isn't it almost as simple as:
cat 16f877.jal blinksample.jal > big.jal
William
ps: Have you tried an 18F device file? I think it has some interesting
pragma statements that I was having trouble finding any docs for.
Joep Suijs
Thanks for the links. Especially the first three chapters from the
tutorial from down-under were usefull (he lost me in chapter 4). It
showed how to handle parenthesis in an universal way and learned how
to create the levels in the tree. My program already recognises them
and needs an extension to actually walk them. Pretty straight-forward,
I expect.
An other thing is to create our own 'input stream', that supports the
paths speficication like the jal compiler and recursive include.
Probably takes some more work, so I'll postpone it for now ;)
> I like the idea fine, but I don't see how, since those output files
> are already obsolete, aren't they? But if you intend to keep those
> files updated, that sounds great.
The svn working copy is now my working directory, so it will be up to date.
> I think you already checked it in, didn't you?
You mean jal.py? Does not run out of the box (needs plex) and I was
not aware of it's function...
> But for blinking LED
> sample, isn't it almost as simple as:
> cat 16f877.jal blinksample.jal > big.jal
Almost ;) Files are in different directories and device files use
include chipdef_jallib -- common constants
> ps: Have you tried an 18F device file? I think it has some interesting
> pragma statements that I was having trouble finding any docs for.
I just tried the largest of them, 18f8680.jal. Needed a modification
or two, but is now parsed without errors and compiles with same two
modifications.
Joep
William
>
> Thanks for the links. Especially the first three chapters from the
> tutorial from down-under were usefull (he lost me in chapter 4). It
> showed how to handle parenthesis in an universal way and learned how
> to create the levels in the tree. My program already recognises them
> and needs an extension to actually walk them. Pretty straight-forward,
> I expect.
Very good news Joep!
> An other thing is to create our own 'input stream', that supports the
> paths speficication like the jal compiler and recursive include.
Good, I had not seen that yet.
> The svn working copy is now my working directory, so it will be up to date.
Just curious what is your working setup? That makefile.do is
interesting...
> You mean jal.py? Does not run out of the box (needs plex) and I was
> not aware of it's function...
Well, it was actually a dead-end, before Antlr, to work on a parser
for JAL. But I think that is what I used to make a big jal file.
Perhaps we should just delete it and go with your custom input-stream
like you described before.
> I just tried the largest of them, 18f8680.jal. Needed a modification
> or two, but is now parsed without errors and compiles with same two
> modifications.
>
Thanks for all your good work! I hope I can spend some time with the
project this week too.
William
Joep Suijs
> Just curious what is your working setup? That makefile.do is
> interesting...
I run windows and my main tool is ultraedit. This means a working
directory needs a ultraedit project file and something to 'make' the
target (whatever this is).
Makefile.do is a recent attempt to create an alternative to make -
less advanced but easier to comprehend configuration. But now I work
on grammar definitions, I see a change I need to apply.
The program is in perl and only tested on windows. If you want I can
provide the program and some preliminary documentation.
Joep
William
>
> I run windows and my main tool is ultraedit. This means a working
> directory needs a ultraedit project file and something to 'make' the
> target (whatever this is).
> Makefile.do is a recent attempt to create an alternative to make -
> less advanced but easier to comprehend configuration. But now I work
> on grammar definitions, I see a change I need to apply.
> The program is in perl and only tested on windows. If you want I can
> provide the program and some preliminary documentation.
>
Hi Joep,
Thanks for the description. It sounds like a very good setup!
I've got an old-fashioned setup here -- For Windows I use Cygwin which
provides gcc and Bash. For editing I mostly use Vim -- not my
favorite editor, but it is available nearly everywhere, and runs on
modest hardware resources. On any given day I may need to work on
Windows (XP, Vista or 7), Ubuntu/Linux, or FreeBSD, over SSH, RDP, or
VNC.
William
Mike@watty
What research on Programming language translation has been done for
the Project?
Has Kyle any other "undocumented" features we might suddenly be using
c.f.
two parameter pseudo vars working as arrays.
accessing information defined in pragmas (i.e. const in Library based
on eeprom on chip def)
Joep Suijs
2010/4/12 Mike@watty <watt...@gmail.com>:
> Did you look at the "Gold" tool and compare it to Antlr?
I did look and did not see any reason to switch. But that's probably
due to a lack of experience on the subject and my current activity
will change that (at least a bit).
Joep
William
> Did you look at the "Gold" tool and compare it to Antlr?
>
Yes, I did look at Gold, thank you for pointing it out. I suspect it
would be a fine choice. Why don't you give it a try? From what I can
tell, Gold supports BNF whereas Antlr supports EBNF, so with a few
hours work, we should be able to 'port' a JAL grammar from Antlr to
Gold or Gold to Antlr.
Antlr seems to have a much bigger following, with many more grammars
already implemented than Gold. http://www.antlr.org/grammar/list
If you like, we can re-organize the SVN here to provide a place for
your Gold work.
We'll continue on with Antlr for now.
Thank you,
William