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
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 On Aug 21, 3:13 pm, Joep Suijs <[email protected]> wrote: > Hi Guys, > > 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 <[email protected]>: > > > Hi Matt, > > > 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) > > > On Aug 21, 6:33 am, mattschinkel <[email protected]> wrote: > >> > 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. > > >> Hey Joep, I was wondering what was happening with this. It's good to > >> 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. > > > -- > > You received this message because you are subscribed to the Google Groups > > "jallib" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/jallib?hl=en. -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
