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.
Vasi On Aug 21, 3:39 pm, funlw65 <[email protected]> wrote: > 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.
