Conclusions for complementary tools but having mikroElektronika 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) On Aug 21, 2:11 pm, funlw65 <[email protected]> wrote: > 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.
