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 at http://groups.google.com/group/jallib?hl=en.
