FORTAN? for AVRs

Go To Last Post
64 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think I've heard mention of FORTAN as a possible alternative for AVRs.
A quick Google search and Forum search was not very fruitful.

Anyone have a lead?

Thanks in advance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow,. that is Retro!

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know about Fortran but I heard about an object oriented COBOL somewhere on sourceforge that could work on the AVR.

HD

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, so I was going senile Dan. COBOL, eh?

I read just before that the GCC compiler supports in addition to C, ADA and FORTRAN. Since C has been implemented, ADA is currently being implemented hasn't someone tried to make a AVR port for FORTRAN yet? Using FORTRAN would certainly fit in with RetroDan's handle...

EDIT:
ADA: http://sourceforge.net/projects/...
COBOL: http://sourceforge.net/projects/...

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I'm desperate I remember using a Fortran to GCC compiler under Linus quite a while back. I could go that route, but FORTRAN is really supposed to compile directly to Machine Code for optimal speed and size.

I'd really appreciate if anyone hears anything along those lines.

Thanks in advance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Retro,
I don't think a language (such as fortran) is a substitute for hardware like the AVR's.
Please expand on your reasoning. You have lost me I'm afraid.
I am beginning to wonder about your veracity. It is hard to comprehend your experience on one hand and your questions on the other.
Pardon me for being blunt, and please correct me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's my fault. In a email I mentioned that several languages are avaliable for the AVR, and put FORTRAN as an example. Searching seems to show that my befuddled mind should have listed FORTH instead. His confusion is due to my confusion :).

This is all silly anyway, since we all know that the only language worth a damn is C! :D (Kidding, no flame wars please...)

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean,
A true gentleman displays his quality.
- and an aussie to boot!
Us whinging pommes should smarten up :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FORTRAN would actually be an execellent language for these AVRs. The core is small, there is very high precision math routines and its commands are very close to the machines code so that minimal converson has to be done, that's why it was chosen as the language for the Super Crays, etc.

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. It's supposed to be basically a straight translation like a macro.

I still program this PDP-11 here in FORTRAN and it really is a great language if you want very fast bug-free, compact code with a very fast turn-around time. Ideal for commercial apps.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

[edit] Self Censored [/edit]

Last Edited: Tue. Mar 14, 2006 - 12:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lets not forget Gotran. It was a two pass Fortran like complier, except it predates Fortran. For the anti-efficiency crowd that is not quite satisfied with ADA, how about the one and only fully optimizing IBM version of the PL1 complier. The only complier I know that will take a RPG-II program, produce reams of errors and default replacement warnings, then actually try and run it as a compiled PL1 program (the entertainment value can probably be enhanced by your favorite alcohol based beverages).

I do not remember any such thing as a one to one relationship between Fortran commands and the machine code to implement it. Are you referring to a tokenized Fortran intermediate output or something like that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Probably because everyone thinks its a relic, but it's still very strong in the egineering community and had over half-a-centure to work-out any and all bugs.

The last strict formal standard: FORTRAN-95, is only ten years old. Prior to that it was FORTRAN-77 and before that FORTRAN-66. It's really the only progamming language that has a strict formal standard that has lasted so long. I get code that's 40 years old and with a few small changes will run fine on a pentium using MF-FORTRAN then take the same code upload it to the PDP with Kermit and Compile it under a 25 year old FORTRAN-77 Compiler that were originally written for some long obsolete computer.

Anyhow, I'm sorry I brought it up in the first place. I just thought there might be a real FORTRAN compiler kicking around so I could port 30 years of FORTRAN programs without any major rewrites.

But, on the other hand, if you ever do hear of a FORTRAN compiler, please let me know.
I'd really appreciate it. Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, I mean the structure of language is such that it can be converted almost straight to machine code. The original FORTAN-66 was practically just a high-level Assembler.The key to FORTRAN programs is that the math is very accurate (It stands for FORmula TRANlastion) and the code produced is very small and very fast.

I really shouldn't have to defend the language, I'd just be interested in a compiler if there is one out there anywhere.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was not attacking the language or asking you to defend it. In fact my last posting was at exactly the same time as your posting, so I did not see your posting until mine was already placed.

I think your desire to use an existing library of Fortran code is perfectly valid. However, promoting it as “Ideal for commercial apps.” was likely to draw some fire from various quarters. BTW, I was not shooting at you :). Its not because Fortran can or cannot be used for commercial applications. The “ideal” description is what will likely bring out people with different opinions in droves. You are not so much defending the language as you are defending your perception of the language. This long established language defends itself very well by its continued existence and user base. This user base obviously does not include very much of the microprocessor community, so people here are bound to promote their own choice as “ideal” or attack yours. It is just another symptom of complier war disease. Sadly, there is no known cure!

Thank you for the clairification.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for the clarification and the heads up.
I'll try to be more cautious. Typical Newbie mistake, I'm sorry, I did not know the landscape was littered with so many land-mines... is this a support forum or a killing field?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FORTRAN ??? COBOL ???

OMG! WHY?
WHYYYYYY ?

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RetroDan wrote:
The key to FORTRAN programs is that the math is very accurate (It stands for FORmula TRANlastion) .

Exactly - and that is where it still excels.
It is a computation-oriented language.

But the AVR is a microcontroller - it is a control-oriented processor.
The AVR is not a particularly good choice if maths is your main concern

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RetroDan
do you use Genrad 227x test machines ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RetroDan wrote:
I think I've heard mention of FORTAN as a possible alternative for AVRs.
A quick Google search and Forum search was not very fruitful.

Anyone have a lead?

Thanks in advance.

There is a GNU FORTRAN->C translator that works well, I've used it once or twice. It might be possible to get that working with gcc for the AVR. I can't think why anyone would want to use FORTRAN these days.

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How about ratfor that translates fortran to c?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was looking into this a little so I would know for sure that Retro is wrong about his efficiency claims. What I found is the opposite -- RetroDan is correct that Fortran is faster for numerical computing. This means that of course, converting the code to C first doesn't make sense.

Now, it is fair to wonder why one would use an AVR for anything numerical, but there could be applications that are mostly embedded but benefit from a touch of scientific grade numerical programming.

So my friend RetroDan, hang in there. There is something about these forums that seem to encourage people to make sarcastic, pithy barbs aimed at the sanity of others. Don't let it bug you.

Now as far as HamsterDan and COBOL, that one I am still trying to figure out. But as people who know him say "HamsterDan, he's the MAN!"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RetroDan wrote:
No, I mean the structure of language is such that it can be converted almost straight to machine code.

C'mon, lay off the smoke. You have just been discussing different architectures in another thread; are you saying that FORTRAN can be converted "almost straight to machine code" on any of them? Smoke. Certain operations that may be lengthy on some architectures may be streamlined on others. For FORTRAN, a PDP11 or VAX core comes to mind.

Burroughs mid-range mainframes were aimed at the business markey and thought in COBOL. Everything was done in BCD, including arithmetic operations. Was there a FORTRAN compiler for that machine line? Yes. Did FORTRAN statements go "almost straight to machine code" ? No way. Did COBOL statements? Yes, some constructs did.

Quote:

The original FORTAN-66 was practically just a high-level Assembler.The key to FORTRAN programs is that the math is very accurate (It stands for FORmula TRANlastion) and the code produced is very small and very fast.

More smoke. Why would math translated from FORTRAN source lines be any more accurate than any other math from any other source language on any CPU? If the machine instructions for c=b+a written in any source language were any better, wouldn't the C/Pascal/COBOL/Java/Python/Monty/... compiler writers generate the same instruction stream?

In another thread you decried the non-orthoganality of the AVR instruction set. Have you read any of the white papers on the AVR architecture? Mr. A & Mr. V worked with IAR to refine the instruction set for -- wait for it -- C. Yes, they packed in stuff so LDI worked on one half of the register set and other operations on the other half. The chip designers didn't want to give up either instruction.

C translates directly to AVR machine code. The code produced is very small and very fast. And contrary to your smoke above, you can look at the Maxim work done comparing different architectures using the links that I have repeatedly posted.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
How about ratfor that translates fortran to c?

RATFOR was a structured variant of FORTRAN that was translated to standard FORTRAN before being compiled.

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
RetroDan wrote:
I think I've heard mention of FORTAN as a possible alternative for AVRs.
A quick Google search and Forum search was not very fruitful.

Anyone have a lead?

Thanks in advance.

There is a GNU FORTRAN->C translator that works well, I've used it once or twice. It might be possible to get that working with gcc for the AVR. I can't think why anyone would want to use FORTRAN these days.

Leon

I mentioned that earlier in the thread. Althought that would one to used FORTRAN I think that the fact it is translated twice MAY not make the resulting code as optimal as a straight translation. FORTRAN compilers are designed to optimization on their target machines.... you know those engineers don't like to waste a thing.

I used the F2C program under linux for quite a while a few years back to port some old code and it worked quite well.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
RetroDan wrote:
The key to FORTRAN programs is that the math is very accurate (It stands for FORmula TRANlastion) .

Exactly - and that is where it still excels.
It is a computation-oriented language.

But the AVR is a microcontroller - it is a control-oriented processor.
The AVR is not a particularly good choice if maths is your main concern

I have to disagree. I think it would be excellent for PID control. At the moment I'm working on a small interpolation program and coding it in ASM.

In FORTRAN it would have only taken about 20 minutes, it would have been small, fast, accurate and bug-free.

Although you can make 'coding errors' it's much for difficult to introduce 'bugs', per se using FORTRAN.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

az10sbum wrote:
I was looking into this a little so I would know for sure that Retro is wrong about his efficiency claims. What I found is the opposite -- RetroDan is correct that Fortran is faster for numerical computing. This means that of course, converting the code to C first doesn't make sense."

A proper FORTRAN implemention will have switches to control the optimizaion within the compiler for the target machine. By using the appropriate switches you can direct the complier to optimize for maximum speed, or minimal size.

I don't use the new FORTRAN-95 standard, as I feel it's got away from it's pure roots. I don't really conside the older FORTRAN-66 or FORTRAN-77 as a high-language per se, they're more like high-level assembly language that although much more primitive than any other high-level languages, it's much more efficient than coding in ASM as there is almost no time spent on debuggin by contrast.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
bobgardner wrote:
How about ratfor that translates fortran to c?

RATFOR was a structured variant of FORTRAN that was translated to standard FORTRAN before being compiled.

Leon

Correct, it's a pre-processor that adds some high-level structures that pure FORTRAN lacks. RATFOR stands for RATional FORtran.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyhow, I really didn't want to open a discussion of the merits of programming in FORTRAN. It's continued use after so many years will speak to that. I was just interested in finding out if there were any ports of FORTRAN to the AVRs.

If you happen to hear of any, please let me know. Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RetroDan wrote:
I was just interested in finding out if there were any ports of FORTRAN to the AVRs.

Does BASCOM help? - BASIC was developed from FORTRAN after all.

(but like others have said FORTAN is a scientific, mathematic language which is hardly suited to the integer only processing possible on an AVR)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Although certainly not in the same league as FORTAN for code optimization, BASIC might be great if you need quick code and not too concerned about code size.

Is there a BASCOM compiler available?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RetroDan wrote:
Is there a BASCOM compiler available?

Suggest you have a squint at:

http://www.atmel.com/products/AV...

That shows you all the 3rd party development tools for AVR and gives the link to BASCOM and several other BASIC that are available.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's simply amazing to me that, AVR has excellent first source tools and one of the largest complements of second source tool suppliers and, we aren't happy with what's out there.

Personally, I think that if you are requiring the "Preceived Precision" of FORTRAN, you might just be in the wrong class of microcontroller. I find this thread really funny because, after almost two years of following AVRFreaks threads, the general opinion is that "Reals" or "Floating Point" is just too costly in machine time and FLASH resources. Most developers seem to prefer "Fixed Point" over "Floating Point".

This whole thread is the equivelent of wanting to put a jet engine on a go-cart. It just doesn't seem to be good logic - FORTRAN in an AVR, that is!!! And if you really think about that, all that will really happen is that, the driver gets sucked into the jet engine and the go-cart crashes and burns.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's no way you'd want to write apps using real or floating math. It's the excellent FORTRAN intefer math routines that would be a boon to AVR programming. Those old machines that first implemented FORTAN did not have much memory so the code had to be very fast and tight. I don't think you could even compare the development time for a complex PID control program written in FORTRAN to one written in AVR assembler. Another boon would be half-a-century of proven FORTRAN routines that could be ported directly because FORTRAN has very strict standards across all platforms.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

microcarl wrote:

This whole thread is the equivelent of wanting to put a jet engine on a go-cart.

That's the kind of go-cart I am looking for. I would control it with an AVR running Fortran PID loops. And it would be fun to watch it run. (Any one want to test drive it for me?)

HD

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RetorDan wrote:

Quote:
Another boon would be half-a-century of proven FORTRAN routines that could be ported directly because FORTRAN has very strict standards across all platforms.

It would only be as good ans the translation from FORTRAN source code to the actual AVR machine code. There would still be trade-offs, compensations and translation errors that would creep into the creation process. So, it would still be no more reliable and probably no more effecient, faster, or significantly better then C, or any other current language.

And it deffenitly would not be prooven until it had some time and history behind it!

Edit:

And you talk about the precision of FORTRAN floats. people bitch about the cost of using 32 bit floats on the AVR now. Moving to 48 or 64 bit precision would only muck up the time and space penalties imposed on the AVR even more.

If you need 64 or 128 bit floating point precision, move to a higher class microcontroller, or pay the penalty in longer function execution times and code and data space requirements.

I am absolutely sure that ImageCraft, IAR, CodeVision, etc. make every effort to get the most effecient floats possible - each acording to their own concept of which trade-offs are more important to their marketing goals.

Again, the tools supplied currently available for the AVR seem to support the class and application level of the AVR.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

Last Edited: Sat. Mar 4, 2006 - 06:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FORTRAN "unproven" with no "history" behind it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rotran wrote:

Quote:
FORTRAN "unproven" with no "history" behind it?

You miss the whole point!

It isn't FORTRAN that's un-prooven! It's would be the translation from the FORTRAN source code to the AVR machine code.

Whose going to make that translation?

How long will it be before that translation would be reliable and bug-free?

And, what makes you so sure that the AVR would be the best archatecture to supprot it's precieved "Marvalous" features.

I mean, too me, FORTRAN has grown to look alot like BASIC.

I really don't think FORTRAN will ever be in the main-stream again because, it just doesn't fit in the world of todays technology. To do that, it would require complete re-vamping of FROTRAN. And it just wouldn't be FORTRAN then, now would it?

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

HamsterDan wrote:
I don't know about Fortran but I heard about an object oriented COBOL somewhere on sourceforge that could work on the AVR.
HD

An OOP Cobol!!!! :lol:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The only value that I can see to having a fortran compiler for the AVR is to allow the use of exiting code, probably scientific in nature.

Otherwise Fortran is so close to Basic that that language may be more appropriate for new development.

DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RetroDan wrote:
It's the excellent FORTRAN intefer math routines that would be a boon to AVR programming.

If your typographical error in this post meant "integer" then what on earth are you talking about? Why should integer maths in FORTRAN be any different to integer maths in C or Pascal or BASIC or any of the other languages available for AVR? What's more the work that's gone into the optimisers of the various C compilers probably means that they'd output far "tighter"/"speedier" integer maths code than some half baked FORTRAN compiler might until it's been under development for several years and it's authors have got as good at optimisation as the C compiler developers have.

This whole thread tickles me - it's a bit like being taught to program at university in Pascal when the commercial world was using FORTRAN, COBOL, PL/1 and so on. There's nothing quite like using the wrong tool for a job!

If you poll commercial developers (not home hobbyists) writing code for AVR microcontrollers (or any other microcontroller probably) you'll probably find 49% use ASM, 49% use C and 2% some other weird and wonderful language. This is no coincidence because C and ASM are the best tools for the job and the other stuff is generally a jet engine on a go-kart!

Cliff

(actually, because Atmel designed AVR in collaboration with IAR and designed it to be "C compiler friendly" that 49:49:2 split might be a bit more biased towards C as the AVR attracts C users perhaps more than other 8 bit controllers)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> It's the excellent FORTRAN intefer math routines that would be a
> boon to AVR programming.

Tell me, what exactly is `excellent' about them?

Old FORTRAN didn't even implement 64-bit integer data types, something
you can already have right now on an AVR with modern compilers (albeit
at a high cost).

> Those old machines that first implemented FORTAN did not have much
> memory so the code had to be very fast and tight.

I don't think it was really all that tight. Sure, it fit into 64 KB
of code, but often you already had to use overlay techniques for
larger programs, so not all parts of the program were in memory
throughout the life-time of the program. Oh, and establishing such an
overlay linker description was a pain in the butt. I think I did it
once or twice, can't remember exactly. (For sure, that technique
doesn't really apply to a flash-ROM controller at all, unless you have
some external storage you could use to reload the overlais from, and
unless you want to sacrifice the eternity it takes to re-flash the ROM
at run-time.)

Next, consider that FORTRAN didn't have anything like `automatic'
variables which only last during the lifetime of a particular
subroutine: every variable required static storage. What a terrible
waste of memory, in particular given that SRAM is still the most
expensive resource in our today's microcontrollers.

> I don't think you could even compare the development time for a
> complex PID control program written in FORTRAN to one written in AVR
> assembler.

I'm not sure what you are trying to tell with that. You mean,
programming in FORTRAN would take even more time than programming in
assembly? ;-) But even if you want to tell the opposite: that's the
very minimal requirement I feel that needs to be met by a higher-level
programming language, to save development time compared to assembly.

> Another boon would be half-a-century of proven
> FORTRAN routines that could be ported directly because FORTRAN has
> very strict standards across all platforms.

You mean half-a-century of unreadable code due to the GRMPFZ-style
``only six characters are significant in identifiers'' policy, due to
cruel things like arithmetic GOTO, due to the lack of reserved words
so you never know when you see an IF whether it's a keyword or an
integer variable, due to the complete lack of structuring elements in
the language (all structure had to be implemented using jumps
aka. GOTO), due to a missing type conversion policy so you had to use
error-prone EQUIVALENCE statements, due to nitty-gritty things like
26HHollerith string constants (mind you, don't miscount the number of
letters!)? I could probably name more of the `benefits' of FORTRAN
the longer I try to remember my FORTRAN days. No, I don't really miss
that time anymore.

Tell you what, the only reason why these half-a-century worth of stuff
still survived is that absolutely nobody (probably not even the
original authors) has ever been able to understand a FORTRAN program
once it was written. They were completely write-only.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My apologies, you are correct, it's not the FORTRAN language that would be unreliable, it's the fresh implementation on AVR. I agree with you there.

As for BASIC, I don't think it is stuitable for any microcontoller environment unless it is a very stripped-down and optimized version. Basic relies too heavily on strings and string I/O and floating-point math which is why any BASIC program is slowly. Any true BASIC is enterpreted whereas FORTRAN is compiled. I think any so-called basic compiler might possibly be just an interpreter run-time core combined with BASIC tokens to give the illusion of compiled code.

Back in the 80s there were a few super-simplistic BASICs (one was called BASCOM for BASic COMpiler) that were sort of dressed-up assembly macros that pseudo-supported many basic command structures but was compiled directly to very optimized ASM code with practically no overhead. Something like that could speed-up development time.

A true basic would be wasted on a microcontroller unless it was connected to some sort of display device as the major benefit of BASIC is it's handling of string which would be wasted and add unneeded overhead for the string support.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

[edit] Self Censored [/edit]

Last Edited: Tue. Mar 14, 2006 - 12:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RetroDan wrote:
Back in the 80s there were a few super-simplistic BASICs (one was called BASCOM for BASic COMpiler) that were sort of dressed-up assembly macros that pseudo-supported many basic command structures but was compiled directly to very optimized ASM code with practically no overhead. Something like that could speed-up development time.

Yup, that's pretty much what the BASCOM available for AVR offers - in fact, apart from Forth, I don't think there is an interpreted language available for AVR - they are all compilers. BASCOM actually looks good for beginners because the "dressed-up assembly" lets you do thinks like (not exactly but close to) "SET TIMER1 TO PERIOD 3ms" and you don't need to worry about CS01 or WGM21 bits and all that confusing nonsense - so it's a good entry point for folks who just want to do something quickly and dont' really care how (a lot of robot programmers fall into this category and you'll find AVR+BASCOM offered on a lot of robot engineering suppliers sites).

At the end of the day I guess there's an argument to say that C is actually the ultimate in "dressed-up assembly macros" which is probably why it's the obvious choice if you aren't going directly for ASM

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm, that BASCOM sounds interesting. I'll have to give it a try. Are you familiar with it?
Does it compile directly to Machine Language or will it spit out an ASM file that can be further tweaked if required?

Also, is that a liscenced commercial product or something a hack like me can use in the public domain?

Thank you very much for the info!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Next time i'm keeping my mouth shut :). This has certainly escalated past a single passing reference in a private email!

I used to use BASCOM all the time, but havn't for quite a while. I'm sure I can be of some use to you if you ever need it, though. BASCOM spits out a HEX file directly which you can then edit/simulate/program in AVRStudio, or simulate/program inside the IDE itself (I like the BASCOM simulator, actually).

BASCOM is a commercial product, but the free version will compile up to 2Kb of machine code. There are no other restrictions placed on the demo version.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

www.netlib.org has source and executables for f2c
also just saw it at http://www.simtel.net/category.p...||||&s=product.date_released|DESC

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
I mean, here I though the AVRFreaks forum was one of the nicest most helpful and friendly forums I've ever seen... but apparently I'm wrong, so please help me by providing some links.

Thank you,
Smiley

Smiley, I agree with you that the AVRFreaks forum is "one of the nicest most helpful and friendly forums I've ever seen." I was commenting about forums in general. Think about it -- The guy asked if anyone knew about a Fortran compiler for the AVR. Although it is an admittedly odd request, one has to agree that the correct answer to the question is simply "No". Instead, he gets four pages of responses, few of which actually answer the question. Very typical of forums (and somewhat amusing), however some people are not prepared for the response and it seemed to be bugging him a little. That was my only point. (And I do really like AVRFreaks)

Peace?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

[edit] Self Censored [/edit]

Last Edited: Tue. Mar 14, 2006 - 12:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RetroDan:

Quote:
Does it compile directly to Machine Language or will it spit out an ASM file
As Dean said, no. I did ask the author about this, and he intends to add asm output to the "professional " version someday. A free version of rvk basic limited to 100 lines of code is available at http://bastoc.com/indexr.shtml. It is a control oriented basic, i.e. no floating point. Jack Tidwell (a forum member) is preparing to release an improved version of the JAVR basic compiler. I am looking forward to that one.

Rick

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Rick.

Does the RVK or JAVR Basic Produce spit-out ASM code, do you know?

Is there a link to the JAVR basic also?

Pages