RVK and JAVR produce asm code. As far as I know, the old version of JAVR is no longer available. (haven't been able to find it) I think I will fire off another email to Jack for an update on the release sched.
Gave the JAVR a quick try on sample code provided. Looks pretty good. You say theres a newer version than the one I picked-up at the link you provided?
Gave the JAVR a quick try on sample code provided. Looks pretty good. You say theres a newer version than the one I picked-up at the link you provided?
Say what???? Are you refering to RVK Basic? I have been unable to find a copy of JAVR. The new version of JAVR Basic is not yet ready for release. It appears that it will be a comercial product. Based on the comments of those that used the earlier free version, I am looking forward to the new one.
f2c is rather Unix-centric in many places, and probably needs a lot of
work in order to compile on an AVR platform at all. It has references
to Unix signals and all such.
g77 (IMHO now called gfortran) allows to fully compile the compiler
but then fails to compile many of the library modules since obviously,
the FORTRAN libraries have a number of references to filesystem IO
(fopen, fseek, ftell, ...) which are rather meaningless for the AVR
(unless you've got an operating system on it) yet which are inherent
part of FORTRAN. I guess with a bit of work (like supplying dummy
implementations in avr-libc for the missing pieces), it could perhaps
be made compile. I doubt there's substantial enough interest for
FORTRAN though that will make someone really do this.
Btw.:
> Of course most of that is lost if it was first translated to C then
> into assembler as it would eliminate the one to one relationship
> bettwen the FORTRAN commands and the machine code to implement it.
I wonder where this perception came from. There was/is generally no
closer relationship between FORTRAN code and machine code than there
is between C and machine code. In fact, some C ideas have been taken
straight from the PDP-11 instruction set where there is no equivalence
in FORTRAN, namely the pre-decrement and post-increment operators on
pointers. Both are implemented as native addressing modes on the
PDP-11, and thus a C compiler could directly generate machine code out
of things like:
while ((c = *src++) != 0)
*dst++ = c;
Also, f2c was renowned for its rather tight code generated even though
there's a C layer between.
Jörg Wunsch
Please don't send me PMs, use email if you want to approach me personally.
Gave the JAVR a quick try on sample code provided...
Say what???? Are you refering to RVK Basic? I have been unable to find a copy of JAVR. The new version of JAVR Basic is not yet ready for release...
Rick
I am so STUPID sometimes, I get fatigues after staying up a few days so I crashed for a while. It was the JVK BASIC that I tried and NOT JAVR and I apologize for any confusion caused thereby.
> www.netlib.org has source and executables for f2c...
Also, f2c was renowned for its rather tight code generated even though
there's a C layer between.
Thanks. I just assumed that with two levels of translation that the resultant code would be bloated with double the overhead and unneeded calls.
Visual FORTRAN? I guess things have moved on since FORTRAN IV! I did my first professional code in Fortran 77 on Vax/VMS.
It is quite fun designing and implementing your own languages, but those "complications" certainly can be time consuming. I wonder what the nearest language to FORTRAN is which also runs on AVR? Ada might be a stretch, there is probably a Pascal somewhere.
So I had to fake it to be a Von Neumann machine as follows: I made every address 1 byte longer than it otherwise would have been. The extra byte told the subroutine whether the address was to ROM or RAM,
That's how __memx works in avr-gcc but it only uses 1 bit, not a whole byte as the memory space indicator. The pointers are 24 bits with 23 bits of address.
The way the keil compiler (the first I know of that did it) solved the problem (for 8051 that have the same passing problem), was by passing 3 bytes where one byte indicated the type of memory.
On some of the newer (and small) AVRs like a 817 everything are memory mapped (aswell), so they will work for general functions (they just have one big problem that they don't have the registers memory mapped)
RVK and JAVR produce asm code. As far as I know, the old version of JAVR is no longer available. (haven't been able to find it) I think I will fire off another email to Jack for an update on the release sched.
Almost forgot about this one. http://www.mikroelektronika.co.yu/english/product/compilers/mikrobasic_avr/index.htm
Rick
- Log in or register to post comments
TopGave the JAVR a quick try on sample code provided. Looks pretty good. You say theres a newer version than the one I picked-up at the link you provided?
Thanks again, eh?
- Log in or register to post comments
TopRetroDan:
Say what???? Are you refering to RVK Basic? I have been unable to find a copy of JAVR. The new version of JAVR Basic is not yet ready for release. It appears that it will be a comercial product. Based on the comments of those that used the earlier free version, I am looking forward to the new one.
Rick
- Log in or register to post comments
Top> www.netlib.org has source and executables for f2c
f2c is rather Unix-centric in many places, and probably needs a lot of
work in order to compile on an AVR platform at all. It has references
to Unix signals and all such.
g77 (IMHO now called gfortran) allows to fully compile the compiler
but then fails to compile many of the library modules since obviously,
the FORTRAN libraries have a number of references to filesystem IO
(fopen, fseek, ftell, ...) which are rather meaningless for the AVR
(unless you've got an operating system on it) yet which are inherent
part of FORTRAN. I guess with a bit of work (like supplying dummy
implementations in avr-libc for the missing pieces), it could perhaps
be made compile. I doubt there's substantial enough interest for
FORTRAN though that will make someone really do this.
Btw.:
> Of course most of that is lost if it was first translated to C then
> into assembler as it would eliminate the one to one relationship
> bettwen the FORTRAN commands and the machine code to implement it.
I wonder where this perception came from. There was/is generally no
closer relationship between FORTRAN code and machine code than there
is between C and machine code. In fact, some C ideas have been taken
straight from the PDP-11 instruction set where there is no equivalence
in FORTRAN, namely the pre-decrement and post-increment operators on
pointers. Both are implemented as native addressing modes on the
PDP-11, and thus a C compiler could directly generate machine code out
of things like:
Also, f2c was renowned for its rather tight code generated even though
there's a C layer between.
Jörg Wunsch
Please don't send me PMs, use email if you want to approach me personally.
- Log in or register to post comments
TopI am so STUPID sometimes, I get fatigues after staying up a few days so I crashed for a while. It was the JVK BASIC that I tried and NOT JAVR and I apologize for any confusion caused thereby.
- Log in or register to post comments
TopThanks. I just assumed that with two levels of translation that the resultant code would be bloated with double the overhead and unneeded calls.
- Log in or register to post comments
TopI agree FORTAN for the AVR would be great.
I hate C so much I tried to write own FORTRAN compiler for the AVR, running on the PC. It was written in Intel Visual FORTAN!
I got quite far actually, and it was more advanced than the Intel Visual Fortan is for the PC.
It has all manner of variable lengths, operator overloading, structures, dynamically relocatble string space and the like.
I was compiling to ASM macros which I could then link in with Atmel .asm files. It didn't produce very compact code.
Moroever, there are complications that were taking too much of my time to fix.
I finally realised why there are differences between argument passing in C and FORTRAN.
A complication that arises in all Harvard architecture machines like the AVR, is that they use different assembler
instructions for addressing program memory (FLASH) compared to data memory (RAM).
But in FORTRAN, all arguments are passed by address. So a subroutine can't know in advaNce whether it is going to
receive the address of a variable in RAM or ROM. So I had to fake it to be a Von Neumann machine as follows:
I made every address 1 byte longer than it otherwise would have been. The extra byte told the subroutine whether
the address was to ROM or RAM, so it could use the approiate assembler instruction.
Now FORTRAN also allows you to pass in the name of a subroutine to use as an argument.
But these addresses are Word addresses while other constants in program memory are byte addresses
so you also have to know the variable type to decide whether to multiply the address by 2 or not.
Then there is NAMED COMMON, arrays of subroutine names or jump addresses and all other manner of other complications
that the AVR architecture creates for FORTRAN.
We need a new language!
The problem I have with C is that I find it even more cryptic than assembler, with all its fussy curly brackets
punctuation marks that are critical to the syntax and the like, and meaningless words like VOID, and you
can't tell what anything is, procedure, array or what have you without looking back at the declarations,
thus making it totally unreadable unless you wrote it yourself!
- Log in or register to post comments
TopVisual FORTRAN? I guess things have moved on since FORTRAN IV! I did my first professional code in Fortran 77 on Vax/VMS.
It is quite fun designing and implementing your own languages, but those "complications" certainly can be time consuming. I wonder what the nearest language to FORTRAN is which also runs on AVR? Ada might be a stretch, there is probably a Pascal somewhere.
Bob.
- Log in or register to post comments
TopPascal-scm for Atmel AVR
Free Pascal Compiler (FPC)
Luna (AVR) (BASIC/Pascal-like)
https://sourceforge.net/projects/avr-ada/
http://libre.adacore.com/ (Download, Free Software, GNAT GPL 2012)
https://www.adacore.com/gnatpro/embedded/avr
http://www.e-lab.de/AVRco/index_en.html
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/embedded/avr/?sortby=file
http://avr.myluna.de/doku.php?id=en:about
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopThere's uLisp for the AVR if you want to explore 1950's vintage computing languages.
- Log in or register to post comments
Top11 YO thread resurrection.
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
- Log in or register to post comments
Top- Log in or register to post comments
TopThe way the keil compiler (the first I know of that did it) solved the problem (for 8051 that have the same passing problem), was by passing 3 bytes where one byte indicated the type of memory.
On some of the newer (and small) AVRs like a 817 everything are memory mapped (aswell), so they will work for general functions (they just have one big problem that they don't have the registers memory mapped)
- Log in or register to post comments
TopPages