JAT presentation
funlw65
I need a link to a .html page on the web which describe JAT project
and how to work with it, and some specific (real) examples.
Vasi
Joep Suijs
Good to see not everybody did forget JAT :) What do you intent to do with it?
As for the html pages: I am afraid there aren't any...
The target directories provide batch/make files to convert a specific
jal source to C and compile it (assumed the proper C compiler is
installed). The source/test directory has .jal files with all
statements that are supported. Feel free to ask me any questions and
create a wiki of your achievements while you're at it ;)
As for the perspective: JAT could support JAL, but will not behave
exactly the same on a detailled level and discussions on this list
learned that that would be unacceptable for some. This in combination
with the lack of potential users led me to the descision to suspend
development.
I also did some research on a C backend for the JAL V2 compiler and
learned this is feasable, but has two major disadvantages over JAT: it
would work for 8 and 16-bit systems only (so no proper ARM support)
and would require a jallib-alike effort for each target family.
Joep
2010/8/18 funlw65 <fun...@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.
>
>
funlw65
On Aug 18, 7:11 pm, Joep Suijs <jsu...@gmail.com> wrote:
> Hi Vasi,
>
> Good to see not everybody did forget JAT :) What do you intent to do with it?
>
programming (my ATmega needs recovering from bad fuses :-( ) but I
thought also would be nice to do some kind of cross development...
programming in JAL for FreeJALduino and generating code for SDCC-
Pinguino and for WinAVR-ATmega16/32/644p.
> As for the html pages: I am afraid there aren't any...
> The target directories provide batch/make files to convert a specific
> jal source to C and compile it (assumed the proper C compiler is
> installed). The source/test directory has .jal files with all
> statements that are supported. Feel free to ask me any questions and
> create a wiki of your achievements while you're at it ;)
>
give a link to JAT page, to present it as a real solution to cross
development... that war between PIC and AVR fans it looks childish to
me.
> As for the perspective: JAT could support JAL, but will not behave
> exactly the same on a detailled level and discussions on this list
> learned that that would be unacceptable for some. This in combination
> with the lack of potential users led me to the descision to suspend
> development.
everything I do on this hobby is with great effort from my family and
also my sponsors (relatives - they all hope this will have some happy
ending like earning some money with) but this does not mean I don't
want to do it. For now, I can make only "waves" about it, keeping it
in the treasure chest.
> I also did some research on a C backend for the JAL V2 compiler and
> learned this is feasable, but has two major disadvantages over JAT: it
> would work for 8 and 16-bit systems only (so no proper ARM support)
> and would require a jallib-alike effort for each target family.
>
passionate people? :-D . Some sort of small steps? One team for SDCC,
one for Arduino and ATmega, etc. But I know that somebody was
interested in ARM development and now probably have no interest on
this... too bad!
Still, I have hopes this is not the end!
All the best,
Vasi(funlw65)
> Joep
>
> 2010/8/18 funlw65 <funl...@gmail.com>:
mattschinkel
> exactly the same on a detailled level and discussions on this list
> learned that that would be unacceptable for some. This in combination
> with the lack of potential users led me to the descision to suspend
> development.
> I also did some research on a C backend for the JAL V2 compiler and
> learned this is feasable, but has two major disadvantages over JAT: it
> would work for 8 and 16-bit systems only (so no proper ARM support)
> and would require a jallib-alike effort for each target family.
hear an update, although not good news. I think a decision needs to be
made on this. Use JAT or C backend to JALV2. Otherwise this will not
proceed any further. Obviously these decisions are not easy.
I still like the "C backend" idea, although JAT is also a good
project. If Kyle was to add support for a 32 bit processor, I am
guessing that your first problem would be solved? If so, I would leave
the decision up to Kyle (weather or not he wants to work on 32 bit
processor support).
Can you explain what you mean by "jallib-alike effort for each target
family". Wouldn't you have to do this with JAT anyways?
Matt.
funlw65
As I understood, for an accurate JAT translation, you need to have
same functions on the other side. A jallib-alike library on every
target.
Identical functions/procedures with the same parameters but having the
internal code specific to every target.
What options are (at least, regarding to PIC and AVR) speaking about C
target?
- There is HI-TECH C for PIC under Windows, Linux, OS-X it was also
for AVR but Microchip ended that.
- There is mikroElektronika compilers, mikroC for PIC (almost all
families) and AVR but under Windows only.
- You have also SDCC for WIndows, Linux, OS X but is for PIC18 only
(PIC16 can't be trusted but also is not the case for this study) - out
of discussion because no library yet. About other compilers I don't
know.
Why to choose only one producer of compilers? Because of the same
library for EVERY target. You can choose mikroElektronika and only
thing you must do is to duplicate his library in Jal, creating a new
project of course (only ONE TASK, maybe two if you must make an
identical C library for ARM), or you can choose WinAVR (WinARM) and
make the same library for every target (HUGE, MULTIPLE TASKS). And
don't forget that there is also mikroPascal for PIC(dsPIC 24/30/33)
and AVR with the same library and all we need in JALv2 are pointers
(please, please, please).
So, I think the mikroElektronika is the easiest "target". It cost
money? But the people involved in production with such targets are
making also money. For others are demo and limited tools at their
disposal..
Vasi(funlw65)
funlw65
libraries as universal library:
---------------------------------------------------------------------------------------------------------------------------------------
mikroElektronika (C, Pascal):
- PIC12, PIC16, PIC18, dsPIC30/33, PIC24
- AVR
- 8051 ?
HI-TECH C (the mikroElektronika library must be ported here):
- PIC32
- PSOC
- ARM
JALv2 - the mikroElektronika library must be ported here.
Vasi(funlw65)
Joep Suijs
The main difference between JAT and a JALV2 C-backend is that JAT is a
translator and JALV2 is a compiler.
JAT translates JAL to C code, but does not compile+link (synthesise).
So it does not need to be complete or fully aware of all details of
the target code. This is left to the C-compiler. This means you can
use logical names (like DDRA) and let the compiler decide (based on
the exact target chip, defined in its include files / libraries).
Also, it is possible to provide a jal procedure structure with C code
as a content to be passed to the C compiler by JAT. And you can use
C-libraries from jal (maybe you need to provide the prototypes).
JALV2 is a read compiler. It takes JAL code as input and converts this
into intermediate code. The only thing left is converting it to
assembler (hex) or C. This means all consants (registers, 'device
file') and (probably available) library functions like pwm, serial
etc. need to be provided in jal. Assuming the sourcecode of the
libraries are available, you need to translate this from C into JAL
for every target chip. Thus, a jallib-alike project for each target
family to create device files an functions to interface with the
hardware.
@32bit support. Kyle told me that JALV2 is basicaly a 16bit compiler
and changing it to 32bit - if possible- is a substantial effort. IMO
there should be a commitment to start such a jallib-alike project for
at least one 32-bit target to consider such an effort.
@PIC12, PIC16, PIC18 support: Boths paths described will add overhead
to the code and it does not make sense to use either one to generate
code for targets that have native support.
@other 8bit targets: Again, with the added overhead you will pay a
price. Arduino is an obvious target since it attracks a lot of
attention. Faster targets are however more likely targets to benefit
from the translation since they can deliver more power than native
target chips.
I expect there might be commitment to start a jallib-alike project for
largers PICs that have similar peripherals as 16f/18f chips. So a C
backend could be an alternative to adding these targets, but does
probably require 32-bit address support anyway. So quite a lot of
effort (32-bit support, the C backend and device files).
As for JAT: this won't be 100% compatible with the current language
which is a major issue for some. An alternative would be to
investigate the major advantages from JAL over C and create a new
language (Yet Another Language?) if it is worth while (adds enough
value over C++).
An other option would be to port the PIC emulator to new targets and
run it as a virtual machine that emulate code generated by the jal
compiler.
Joep
2010/8/21 funlw65 <fun...@gmail.com>:
funlw65
if you have the same functions/procedures on the other side... but
having problems at data types for "bigger" targets
One major flaw which Jallib have is the way you are working with
libraries and constants... you can't find the same on C and Pascal
language and you will have problems in porting JAL programs to those
targets...
Some how, we are sending parameters to libraries in many cases (we are
messing with global constants/variables) and this is not possible in
Pascal and C.... parameters are only for functions/procedures. Which
can be a plus if you're not interested in porting (but this it limits
your horizon and the technology is not stepping back)...
It is a little off-topic but I think is still related...
Vasi
funlw65
because the way they are designed/used.
It require a redesign of Jallib, using the standard rules of C and
Pascal.
Vasi
mattschinkel
family". I'm sure libraries and samples for other devices will be
welcome here. Some jallib libraries do not use register names, so
these libraries would work on other devices.
>IMO there should be a commitment to start such a jallib-alike project for
>at least one 32-bit target to consider such an effort.
Matt.
Joep Suijs
> Well, I referred JAT as a Pascal to C translator... which is possible
> if you have the same functions/procedures on the other side... but
> having problems at data types for "bigger" targets
Well... the data type size can probably be fixed.
But what is the major advantage to program in JAL in stead of Pascal or C?
> One major flaw which Jallib have is the way you are working with
> libraries and constants... you can't find the same on C and Pascal
> language and you will have problems in porting JAL programs to those
> targets...
> Some how, we are sending parameters to libraries in many cases (we are
> messing with global constants/variables) and this is not possible in
> Pascal and C.... parameters are only for functions/procedures.
Don't confuse JAL libraries with C libraries. JAL libraries are common
source files, while C libraries are pre-compiled. If you use
sourcefiles like jal-libraries in C too.
>So, the major conclusion is that the Jallib libraries are not portable
> because the way they are designed/used.
> It require a redesign of Jallib, using the standard rules of C and
> Pascal.
This is true, but I don't see why this is an issue.
Joep
Joep Suijs
2010/8/21 mattschinkel <mattsc...@hotmail.com>:
> There does not need to be a "jallib-alike effort for each target
> family".
If you mean there are a dozen libraries that are not device-specific,
then you're right. And if you mean jallib supports over 300 devices
and most other families are smaller, you're right too. And since we
are more experienced now, we can probably work more efficient and it
takes only half the effort.
> I'm sure libraries and samples for other devices will be
> welcome here.
I am not arguing it should be separate, on the contrary. My statement
is it will take a lot of effort, maybe more than many of us are aware
of, and much of which is executed by Rob.
Joep
mattschinkel
never :)
Matt.
On Aug 21, 10:40 am, Joep Suijs <jsu...@gmail.com> wrote:
> Hi Matt,
>
> 2010/8/21 mattschinkel <mattschin...@hotmail.com>:> There does not need to be a "jallib-alike effort for each target
funlw65
> Well... the data type size can probably be fixed.
> But what is the major advantage to program in JAL in stead of Pascal or C?
Pascal support the same number of devices (or almost) but it lacks
only at library part (this can be fixed).
JALv2, is available also to other OSes than Windows.
> Don't confuse JAL libraries with C libraries. JAL libraries are common
> source files, while C libraries are pre-compiled. If you use
> sourcefiles like jal-libraries in C too.
Pascal, having in mind the portability of my sources:
Limiting myself to have parameters only in functions/procedures,
including libraries only at the upper part of the source, etc...making
an easy life for the translator.
A portable Jallib (and all applications which use it) is possible this
way. The problem is, you make the same set of functions/procedures for
every target, or adopt an existing set of functions/procedures? This
is why I gave the example with MikroElektronika libraries - they have
common libraries (at naming and parameter level) on different families
of processors.
Again:
is not an explicit request. If you can do a better job in C or Pascal
for that target, then all of this is useless.
Vasi
mattschinkel
power target family would be sufficient, and one C compiler. I don't
see the point in supporting more low power target chips.
So, if Kyle is not willing to add 32bit support to JalV2 over time,
then we could continue with JAT. If we where to choose one C compiler
I think JAT could act exactally like JALv2. Leave the decision up to
Kyle, since he did not agree with JAT.
>But what is the major advantage to program in JAL in stead of Pascal or C?
Having a project stop because of a decision that can't be resolved
seems silly to me. Please try to resolve this so we can move forward.
Matt.
Joep Suijs
> I don't even think we need to concentrate on "many targets". One high-
> power target family would be sufficient, and one C compiler. I don't
> see the point in supporting more low power target chips.
Arduino related stuff seems to be hot.
> So, if Kyle is not willing to add 32bit support to JalV2 over time,
> then we could continue with JAT. If we where to choose one C compiler
> I think JAT could act exactally like JALv2. Leave the decision up to
> Kyle, since he did not agree with JAT.
Iirc he did not say he disagreed. He asked to consider the alternative
of a C backend, which I did.
Choosing either option does however have it's impact (compatibility vs
maintenance), which seems to be ignored.
>>But what is the major advantage to program in JAL in stead of Pascal or C?
> The syntax, and jallib are the major advantages.
Could you be more specific what of the syntax are a major advantage
over Pascal or C++? It should justify the effort *and* the lack of
features of these languages that are not in JAL.
> Having a project stop because of a decision that can't be resolved
> seems silly to me.
This is not the case. We have two projects, both of which can be
continued. It is however wise for each of them to consider the effort
required and the result that can be achieved.
JAT is my personal favorite, but dit does create an other 'JAL'
branche and there is little interest in the result. The C backend is
much cleaner, but don't think this will be successful due to the
inability to use target C libraries and since I did not yet heard a
clear advantage of JAL over C.
Joep
mattschinkel
> Arduino related stuff seems to be hot.
output different then JAL. Is it the processor type? or is it the C
Compiler? In either case, you would be able to tell JAT what you are
going to use so the output will be the same.
> Iirc he did not say he disagreed. He asked to consider the alternative
> of a C backend, which I did.
>
> Choosing either option does however have it's impact (compatibility vs
> maintenance), which seems to be ignored.
> Could you be more specific what of the syntax are a major advantage
> over Pascal or C++? It should justify the effort *and* the lack of
> features of these languages that are not in JAL.
compared to other languages (mainly C), and are quite important. As
for other features, JAL may have them some day.
> This is not the case. We have two projects, both of which can be
> continued. It is however wise for each of them to consider the effort
> required and the result that can be achieved.
> JAT is my personal favorite, but dit does create an other 'JAL'
> branche and there is little interest in the result. The C backend is
> much cleaner, but don't think this will be successful due to the
> inability to use target C libraries and since I did not yet heard a
> clear advantage of JAL over C.
file to be later compiled by a C compiler. Procedures written in C
could be easily added to the output, or even to the JAL code if kyle
adds support.
Matt.
Joep Suijs
> Good syntax, readability, learning curve are all great features of JAL
> compared to other languages (mainly C), and are quite important. As
> for other features, JAL may have them some day.
What of the JAL syntax is better than C and why? What's the difference
in learning curce, e.g. related to Arduino? And what are those great
features (except longer vars, of course) that are unique for JAL?
I am not saying I disagree, I just want to understand what you think
is the added value of JAL over, say Arduino / C. So please be
specific.
> Why can't C backend use C libraries? I thought the output would be a C
> file to be later compiled by a C compiler. Procedures written in C
> could be easily added to the output, or even to the JAL code if kyle
> adds support.
Adding functions and varialbes C-compile-time is easy, but you can't
use them in your JAL program when they are not defined in JAL.
(actually, you currently can use functions by using prototypes due to
a compiler bug. But that will be changed and there is no similar way
to specify variables).
And of course it's all software, so almost everything can be made
possible if you have unlimited resources. But if the list of required
changes keeps growing, it becomes less likely that it will be actually
implemented.
Joep
mattschinkel
> branche and there is little interest in the result.
Since it is only C code, the final "result" will be totally dependent
on the C compiler. So therefore, the result cannot be exactly the same
as JAL in either case.
I think you where talking about how some may not be interested in the
final product from JAT, but I don't see how it is different then the
output of JALv2 implementation. For this reason, both ways are equal
except for additional features such as implementing C libraries in
JAL.
Another suggestion would be to try to work with kyle to put your JAT
inside the JALv2 compiler and use command line parameters if you wish
to use JAT. You could add a pragma to specify what C compiler you wish
to use. Each C compiler can be well tested for same calculations
compared to JALv2.
Matt.