* Compiler for Z80/6510 @ 1999-11-24 0:00 Lutz Donnerhacke 1999-11-24 0:00 ` Wil ` (3 more replies) 0 siblings, 4 replies; 50+ messages in thread From: Lutz Donnerhacke @ 1999-11-24 0:00 UTC (permalink / raw) Does anyone know a working Ada95 compiler for Z80 (U880) and 6510/6502 microcontrolers? ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-24 0:00 Compiler for Z80/6510 Lutz Donnerhacke @ 1999-11-24 0:00 ` Wil 1999-11-25 0:00 ` Lutz Donnerhacke 1999-11-24 0:00 ` Frank Klemm ` (2 subsequent siblings) 3 siblings, 1 reply; 50+ messages in thread From: Wil @ 1999-11-24 0:00 UTC (permalink / raw) On 24 Nov 1999 09:05:40 GMT, lutz@iks-jena.de (Lutz Donnerhacke) wrote: >Does anyone know a working Ada95 compiler for Z80 (U880) and 6510/6502 >microcontrolers? Back when I was still programming the 6502 in assembly, they were running at less than a MHz/sec. I wouldn't even program this beast in C. Forget Ada! Will ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-24 0:00 ` Wil @ 1999-11-25 0:00 ` Lutz Donnerhacke 1999-11-25 0:00 ` Robert Dewar 0 siblings, 1 reply; 50+ messages in thread From: Lutz Donnerhacke @ 1999-11-25 0:00 UTC (permalink / raw) * Wil wrote: >* lutz@iks-jena.de (Lutz Donnerhacke) wrote: >>Does anyone know a working Ada95 compiler for Z80 (U880) and 6510/6502 >>microcontrolers? >Back when I was still programming the 6502 in assembly, they were running at >less than a MHz/sec. I wouldn't even program this beast in C. Forget Ada! The common experience is, that high level languages result in slow and bloated code. But this must not be true. There is no reason for such compilers despite laziness of developers (it's an expensive development). For most modern processors hand written assembler will be slower than a compiler output. The complexity of scheduling and computation dependencies can be handled by a human in hundreds of hours, but a compiler can do this in a few seconds in respect to all possible optimization methods. You might produce a better code for a small time critical loop but not overall. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-25 0:00 ` Lutz Donnerhacke @ 1999-11-25 0:00 ` Robert Dewar 1999-11-25 0:00 ` Peter Milliken 1999-11-26 0:00 ` Vladimir Olensky 0 siblings, 2 replies; 50+ messages in thread From: Robert Dewar @ 1999-11-25 0:00 UTC (permalink / raw) In article <slrn83ptfb.kn.lutz@taranis.iks-jena.de>, lutz@iks-jena.de (Lutz Donnerhacke) wrote: > The common experience is, that high level languages result in > slow and bloated code. But this must not be true. There is no > reason for such > compilers despite laziness of developers (it's an expensive > development). Actually this is very often the result of programmers who program in the high level language blissfully unaware of the consequences of what they write. It is common today (though worrisome to me) that people write in a language like Ada without even knowing machine code at all, let alone having a good idea of the relation of the source they write to the machine code being compiled for their particular machine. Certainly if you write Ada carefully using GNAT, you will get perfectly efficient code, suitable for use on small micro controllers if you do a GNAT port for such a device (perfectly practical for those microcontrollers with existing gcc ports). > For most modern processors hand written assembler will be > slower than a > compiler output. The complexity of scheduling and computation dependencies > can be handled by a human in hundreds of hours, but a compiler can do this > in a few seconds in respect to all possible optimization methods. This is conventional wisdom, but is quite wrong. An experienced assembly language programmer can still do better than any compiler. It is hard work, but in fact on machines that are the HARDEST to program by hand, e.g. the Intel i860, it is still the case that BLAS for standard matrix operations is far more efficient than any compiler generated code. True, most people cannot write efficient assembler language, for any machine. And what you say is of course true for them, but the idea that wonderful modern compilers can generate amazing code better than skilled humans can is just plain wrong. > You might produce a better code for a small time critical loop > but not overall. Well that depends on how much time and effort you spend! And of course small time critical loops are the only place where code quality matters for time. Now on micrcontrollers you are typically worried about space, and that of course is much worse, since the entire application has to be coded aggressively. I once wrote a full symbolic two pass assembler for a machine with advanced features like expression parsing and literal pool managaement for a 4K byte machine. THe entire assembler could assemble itself in the 4K bytes, which had to hold the entire code for the assembler (no overlays possible, no external disks), and the entire symbol table for the assembly (those were the days :-). The symbol table by the way contained about 600 symbols for this particular case. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-25 0:00 ` Robert Dewar @ 1999-11-25 0:00 ` Peter Milliken 1999-11-26 0:00 ` Tarjei Jensen ` (2 more replies) 1999-11-26 0:00 ` Vladimir Olensky 1 sibling, 3 replies; 50+ messages in thread From: Peter Milliken @ 1999-11-25 0:00 UTC (permalink / raw) G'Day Robert, Robert Dewar wrote: <snip> > True, most people cannot write efficient assembler language, > for any machine. And what you say is of course true for them, > but the idea that wonderful modern compilers can generate > amazing code better than skilled humans can is just plain wrong. Would you care to comment then on the paper written by Lawlis and Elam which was published in Tri-Ada '92 titled "Ada Outperforms Assembly: A Case Study" where, in point 6, they draw conclusions such as: compiler optimisation has reached such a state of the art that it can implement "hundreds of heuristics from a library of knowledge in this area of technology" and generate code which can "beat assembly code in both size and performance"? I am curious, on the one hand we have this paper (advertised in the Ada Home page) and on the other hand, experienced compiler writers such as yourself. These statements seem to contradict each other. I do not have any experience in compiler writing but I have been prepared to accept the paper at it's face value (having no way to confirm or deny :-)). Did Lawlis and Elam get it wrong? Were they correct for their particular circumstances and environment? I have shown the paper to non Ada software engineers and received various responses, the worst being open ridicule and statements that the paper must be a pure fabrication. Thanks Peter ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-25 0:00 ` Peter Milliken @ 1999-11-26 0:00 ` Tarjei Jensen 1999-11-26 0:00 ` Ed Falis 1999-11-26 0:00 ` Robert Dewar 2 siblings, 0 replies; 50+ messages in thread From: Tarjei Jensen @ 1999-11-26 0:00 UTC (permalink / raw) Peter Milliken wrote >I am curious, on the one hand we have this paper (advertised in the Ada >Home page) and on the other hand, experienced compiler writers such as >yourself. These statements seem to contradict each other. I do not have >any experience in compiler writing but I have been prepared to accept >the paper at it's face value (having no way to confirm or deny :-)). Did >Lawlis and Elam get it wrong? Were they correct for their particular >circumstances and environment? I have shown the paper to non Ada >software engineers and received various responses, the worst being open >ridicule and statements that the paper must be a pure fabrication. If my memory is right, they did this on a signal processor. Assembly language programming on such a device is supposed to be very difficult. There are a lot of problems with scheduling of instructions and rather arcane rules for what can be done. It is easy for a compiler to keep track of these rules, but hard for humans. This of course does not apply to ordinary processors. So keep this in mind when reading the paper. Greetings, ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-25 0:00 ` Peter Milliken 1999-11-26 0:00 ` Tarjei Jensen @ 1999-11-26 0:00 ` Ed Falis 1999-11-26 0:00 ` Robert C. Leif, Ph.D. 1999-12-06 0:00 ` Richard D Riehle 1999-11-26 0:00 ` Robert Dewar 2 siblings, 2 replies; 50+ messages in thread From: Ed Falis @ 1999-11-26 0:00 UTC (permalink / raw) On Thu, 25 Nov 1999 23:38:20 GMT, Peter Milliken <peter.milliken@australia.boeing.com> wrote: > Would you care to comment then on the paper written by Lawlis and Elam > which was published in Tri-Ada '92 titled "Ada Outperforms Assembly: A > Case Study" where, in point 6, they draw conclusions such as: compiler > optimisation has reached such a state of the art that it can implement > "hundreds of heuristics from a library of knowledge in this area of > technology" and generate code which can "beat assembly code in both size > and performance"? > > I am curious, on the one hand we have this paper (advertised in the Ada > Home page) and on the other hand, experienced compiler writers such as > yourself. These statements seem to contradict each other. I do not have > any experience in compiler writing but I have been prepared to accept > the paper at it's face value (having no way to confirm or deny :-)). Did > Lawlis and Elam get it wrong? Were they correct for their particular > circumstances and environment? I have shown the paper to non Ada > software engineers and received various responses, the worst being open > ridicule and statements that the paper must be a pure fabrication. > > Thanks > Peter My take on it, having been involved in Ada compilers for a long time, is that an optimizing compiler can do well compared to the average programmer, turned to assembly language. But, a good assembly programmer for a given architecture can do better. This isn't rocket science - human intelligence generally beats what we can simulate with machines. - Ed ^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: Compiler for Z80/6510 1999-11-26 0:00 ` Ed Falis @ 1999-11-26 0:00 ` Robert C. Leif, Ph.D. 1999-11-27 0:00 ` Florian Weimer ` (2 more replies) 1999-12-06 0:00 ` Richard D Riehle 1 sibling, 3 replies; 50+ messages in thread From: Robert C. Leif, Ph.D. @ 1999-11-26 0:00 UTC (permalink / raw) To: comp.lang.ada From: Bob Leif To: Comp.Lang.Ada I attended the original presentation. I believe the key was it was possible for the compiler by brute force to try a huge number of possibilities. I also believe that the CPU was a DSP. DSPs can have peculiar architectures that can be better suited for machine than human analysis. In any event, if a computer can beat a chess grand-master, it should be possible to beat a human creating assembly code. Again, being possible need not mean that it is practical for all situations today. -----Original Message----- From: USENET News Admin @flash [mailto:news@sd.aonix.com]On Behalf Of Ed Falis Sent: Thursday, November 25, 1999 7:36 PM To: comp.lang.ada@ada.eu.org Subject: Re: Compiler for Z80/6510 On Thu, 25 Nov 1999 23:38:20 GMT, Peter Milliken <peter.milliken@australia.boeing.com> wrote: > Would you care to comment then on the paper written by Lawlis and Elam > which was published in Tri-Ada '92 titled "Ada Outperforms Assembly: A > Case Study" where, in point 6, they draw conclusions such as: compiler > optimisation has reached such a state of the art that it can implement > "hundreds of heuristics from a library of knowledge in this area of > technology" and generate code which can "beat assembly code in both size > and performance"? > > I am curious, on the one hand we have this paper (advertised in the Ada > Home page) and on the other hand, experienced compiler writers such as > yourself. These statements seem to contradict each other. I do not have > any experience in compiler writing but I have been prepared to accept > the paper at it's face value (having no way to confirm or deny :-)). Did > Lawlis and Elam get it wrong? Were they correct for their particular > circumstances and environment? I have shown the paper to non Ada > software engineers and received various responses, the worst being open > ridicule and statements that the paper must be a pure fabrication. > > Thanks > Peter My take on it, having been involved in Ada compilers for a long time, is that an optimizing compiler can do well compared to the average programmer, turned to assembly language. But, a good assembly programmer for a given architecture can do better. This isn't rocket science - human intelligence generally beats what we can simulate with machines. - Ed ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-26 0:00 ` Robert C. Leif, Ph.D. @ 1999-11-27 0:00 ` Florian Weimer [not found] ` <01bf38cb$be9b2b60$022a6282@dieppe> 1999-11-28 0:00 ` Robert Dewar 2 siblings, 0 replies; 50+ messages in thread From: Florian Weimer @ 1999-11-27 0:00 UTC (permalink / raw) "Robert C. Leif, Ph.D." <rleif@rleif.com> writes: > In any event, if a computer can beat a chess grand-master, it should be > possible to beat a human creating assembly code. Again, being possible need > not mean that it is practical for all situations today. No, it's impossible, really. Every assembly language coder can use the output of a compiler if it's better than the code he is able to write. A computer program doesn't have this option, of course. ^ permalink raw reply [flat|nested] 50+ messages in thread
[parent not found: <01bf38cb$be9b2b60$022a6282@dieppe>]
* Re: Compiler for Z80/6510 [not found] ` <01bf38cb$be9b2b60$022a6282@dieppe> @ 1999-11-28 0:00 ` Robert Dewar 1999-11-28 0:00 ` Robert A Duff 1999-11-30 0:00 ` Pascal Obry 0 siblings, 2 replies; 50+ messages in thread From: Robert Dewar @ 1999-11-28 0:00 UTC (permalink / raw) In article <01bf38cb$be9b2b60$022a6282@dieppe>, > I'am really for a compiler optimizing my code and I want me to > care about readability, maintenability and overall desing of > my software. In do not want to know what going > on behind the scene ! Fine, but (a) everyone agrees with this, and (b) this is not relevant to the thread. The thread is not about whether it is reasonable to write anything in assembler, it is the interesting technical issue of whether compilers can do a better job than expert humans writing assembler language. That's an interesting issue, but does not have much to do with the issue of whether software *should* be written in ASM! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-28 0:00 ` Robert Dewar @ 1999-11-28 0:00 ` Robert A Duff 1999-11-30 0:00 ` Pascal Obry 1 sibling, 0 replies; 50+ messages in thread From: Robert A Duff @ 1999-11-28 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: >...The thread is not about whether it is > reasonable to write anything in assembler, it is the interesting > technical issue of whether compilers can do a better job than > expert humans writing assembler language. ... I think that's a meaningless question, unless you're willing to specify how much time and money one is allowed to spend. Is it fair game to write a brute-force optimizer that takes exponential time (in the size of the program)? Is it fair to give the programmer an arbitrarily long time to think about it? Are you willing to totally rewrite 100,000 lines of code when one minor change is made? How big is the program anyway? It seems to me that unless there are limits, the question is pointless. - Bob ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-28 0:00 ` Robert Dewar 1999-11-28 0:00 ` Robert A Duff @ 1999-11-30 0:00 ` Pascal Obry 1 sibling, 0 replies; 50+ messages in thread From: Pascal Obry @ 1999-11-30 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1797 bytes --] Robert Dewar <robert_dewar@my-deja.com> a �crit dans le message : 81putt$sa8$1@nnrp1.deja.com... > > Fine, but (a) everyone agrees with this, and (b) this is not > relevant to the thread. The thread is not about whether it is > reasonable to write anything in assembler, it is the interesting > technical issue of whether compilers can do a better job than > expert humans writing assembler language. That's an interesting > issue, but does not have much to do with the issue of whether > software *should* be written in ASM! Ok, fine but I do not find this question really useful :-) I do not want to be compared to an optimizer, this is not my job. Again maybe some human will be able to write pretty good ASM optimized code, but what's the point ? This is a nice experimental competition but I when it comes to maintaining this code the experiment become a nightmare! So as a pure competition fine but I found the time spent to become a full human-optimizer-for-asm-code not a good investement :-) Pascal. -- --|------------------------------------------------------------ --| Pascal Obry Team-Ada Member | --| | --| EDF-DER-IPN-SID- T T I | --| Intranet: http://cln46gb | --| Bureau N-023 e-mail: pascal.obry@edf.fr | --| 1 Av G�n�ral de Gaulle voice : +33-1-47.65.50.91 | --| 92141 Clamart CEDEX fax : +33-1-47.65.50.07 | --| FRANCE | --|------------------------------------------------------------ --| --| http://ourworld.compuserve.com/homepages/pascal_obry --| --| "The best way to travel is by means of imagination" ^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: Compiler for Z80/6510 1999-11-26 0:00 ` Robert C. Leif, Ph.D. 1999-11-27 0:00 ` Florian Weimer [not found] ` <01bf38cb$be9b2b60$022a6282@dieppe> @ 1999-11-28 0:00 ` Robert Dewar 2 siblings, 0 replies; 50+ messages in thread From: Robert Dewar @ 1999-11-28 0:00 UTC (permalink / raw) In article <NBBBJNOMKDIAJALCEFIJAEMFDFAA.rleif@rleif.com>, comp.lang.ada@ada.eu.org wrote: > In any event, if a computer can beat a chess grand-master, it > should be possible to beat a human creating assembly code. > Again, being possible need > not mean that it is practical for all situations today. Chess is actually pretty trivial compared to the problem of generating optimal code in a compiler. Even the most trivial models of code generation are immediately NP complete, and very difficult problems computationally. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-26 0:00 ` Ed Falis 1999-11-26 0:00 ` Robert C. Leif, Ph.D. @ 1999-12-06 0:00 ` Richard D Riehle 1 sibling, 0 replies; 50+ messages in thread From: Richard D Riehle @ 1999-12-06 0:00 UTC (permalink / raw) In article <1103_943587334@DZOG-CHEN>, falis@ma.aonix.com (Ed Falis) wrote: >My take on it, having been involved in Ada compilers for a long time, is >that an optimizing compiler can do well compared to the average >programmer, turned to assembly language. But, a good assembly >programmer for a given architecture can do better. This isn't rocket >science - human intelligence generally beats what we can simulate with >machines. It has been a long time since I have written assembler language programs, but I recall how we used to take advantage of all sorts of little tricks that an optimizer would not dare to assume. We could turn data into instructions and instructions into data, take advantage of knowledge concerning register contents at a specific point in the execution cycle and use that register in obscure ways. By knowing all of the instructions in a CISC set, one can do software contortions one would not expect of a compiler. If this makes you wonder about maintainability, you wonder correctly. In the long run, the maintainability of the compiler-generated code has significant advantages over the hand-tinkering we so loved to do in those primeval days of assembler only. There is a certain tendency to elitism here, as well. "Only whimps and sissies use compilers." Robert Dewar is fond of emphasizing "readability over writeability." It is not unusual for an assembler programmer to write a program that is highly efficient but totally unreadable, or contains instructions that seem to make no sense at all. "Why are there six successive NOP's in this code?" "Why does this instruction add Hex FFFF to this register?" Yes, a good assembler programmer can write more efficient code. It will even work until someone updates the instruction set or changes the timing characteristics of the processor. Richard Riehle http://www.adaworks.com ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-25 0:00 ` Peter Milliken 1999-11-26 0:00 ` Tarjei Jensen 1999-11-26 0:00 ` Ed Falis @ 1999-11-26 0:00 ` Robert Dewar 1999-11-26 0:00 ` Robert A Duff 2 siblings, 1 reply; 50+ messages in thread From: Robert Dewar @ 1999-11-26 0:00 UTC (permalink / raw) In article <383DC86C.19A6F176@australia.boeing.com>, Peter Milliken <peter.milliken@australia.boeing.com> wrote: > G'Day Robert, > I am curious, on the one hand we have this paper (advertised in the Ada > Home page) and on the other hand, experienced compiler writers such as > yourself. People have often made claims that compilers do much better than the best assembly language. First of all this is on its face absurd, since the compilers are only generating assembly language in any case. So it must be a case about competence of the assembly language programmers. Since competence of assembler language programmers can easily vary over two orders of magnitude, it is not surprising that different people come to different conclusions. In practice, really skilled assembly language programmers (there are very few around, especially these days), can always outrun any compiler given enough time and effort. That does not mean the paper is invalid, it just means that it should always remind people that it is talking about typical assembly language programmers. I once wrote an Ada 83 parser in x86 assembler to demonstrate what can be achieved. This is a full parser for the official syntax of Ada 83, and of course includes a lexical analyzer. It finds the first error, and then quits, giving a reasonably informative error message. DASC is 14K bytes long, but this is deceptive, since over half this space is text for error messages. I had not run it for a while on a modern PC, but I just ran it on a file with 6 million lines of Ada source (the file size was just under 100 megabytes). It took about 7 seconds to parse the 6 million lines of source on a PC, giving a speed of approximately 50 million lines a minute (this is mostly I/O time in fact). Now this is VERY aggressive code, but I can pretty much promise you that no Ada compiler comes close or is likely to in the future. A student of Paul Hilfinger's analyzed this code to understand where it's speed advantages came from, and concluded that some, but not all of them, could be achieved with entirely new optimization techniques. He wrote an interesting paper called "Galactic Optimization" but I think it was never published. Briefly what happens in very aggressive assembly coding is that you plan the high level data structures and algorithms of the program knowing exactly what is and is no efficient on the underlying machine. Now of course NO ONE is advocating that ordinary coding be done at this level, and further more, the number of people who could duplicate DASC even in assembly language is very small [in earlier days, I probably wrote a million lines of delivered commercial assembly language for various machines and I got quite good at it :-)] Robert Dewar P.S. I definitely think that compiler writers need to be aware of how to write efficient assembly language, and surprisingly, this is not always the case! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-26 0:00 ` Robert Dewar @ 1999-11-26 0:00 ` Robert A Duff 1999-11-27 0:00 ` Robert Dewar 1999-12-01 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 50+ messages in thread From: Robert A Duff @ 1999-11-26 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > In practice, really skilled assembly language programmers (there > are very few around, especially these days), can always outrun > any compiler given enough time and effort. True, but of course there isn't usually enough time and effort. Also, in my experience working on large assembly-language programs, maintainence is the big issue. Eg, suppose there'a 300-line procedure written in assembly, and you need to add some code, or maybe add a new parameter. Do you completely redo the hand-crafted register allocation (which indeed is very efficient)? Or do you minimize the amount of code that has to be changed, thereby reducing the probability of bugs? In many cases, it's irresponsible to do the former. Compare that to a high-level language, where register allocation is completely redone (by the stupid compiler) every time you change the program. - Bob ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-26 0:00 ` Robert A Duff @ 1999-11-27 0:00 ` Robert Dewar 1999-12-01 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 50+ messages in thread From: Robert Dewar @ 1999-11-27 0:00 UTC (permalink / raw) In article <wcc3dtsvqy2.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > Do you completely redo the hand-crafted register allocation > (which indeed is very efficient)? Or do you minimize the amount of code > that has to be changed, thereby reducing the probability of bugs? > In many cases, it's irresponsible to do the former. Well the answer is that if you are aiming at optimal code, you certainly redo the register allocation. I remember one incident when Ken Belcher and I were writing SPITBOL/370 which is entirely in BAL. There was a bug that needed fixing in a routine that was maybe 100 lines long, and we both kept putting it off. Finally I came in one day, and said "I fixed that bug .... but there is an extra LR in the middle of the routine" Ken answered immediately "Oh well if you are willing to leave in junk code like that the fix is trivial", and we both new without discussion EXACTLY the issue, namely that the register allocation had to be completely redone for the entire routine to avoid this one register-register move in the middle of it. Eventually it got fixed properly :-) But this is not to suggest for a moment that ANYTHING should be written at this level these days, we can afford to waste some machine time to avoid the maintenance nightmares that Bob quite rightly alludes to! Still it was amazing what could be achieved (the SPITBOL lexer and parser used the TRT instruction extensively, and SPITBOL compiles at millions of lines a minute on a modern mainframe). Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-26 0:00 ` Robert A Duff 1999-11-27 0:00 ` Robert Dewar @ 1999-12-01 0:00 ` Robert I. Eachus 1999-12-02 0:00 ` Larry Kilgallen 1999-12-03 0:00 ` Robert Dewar 1 sibling, 2 replies; 50+ messages in thread From: Robert I. Eachus @ 1999-12-01 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com wrote: > In practice, really skilled assembly language programmers (there > are very few around, especially these days), can always outrun > any compiler given enough time and effort. Once, a long time ago, I taught the APL section of a Computing Languages course right after the PL/I section. (As I said, this was a long time ago.) The students were using an IBM 3033U mainframe. (As I said...) The last assignment for the PL/I segment was to write a program to generate magic squares in Ada. In the first APL session (before the assignment was due.) I put a $20 bill on the lecturn and said I'd give one to anyone whose submitted PL/I program was faster than the following APL code. (APL one-liner omitted to spare eyesight.) I then proceded to explain some of the reasons why an interpreted language could be a reasonable choice for many applications. One student who probably didn't really need the course asked after class how fast the APL version ran. I handed him a listing showing another one liner which timed the first program, and the time: 87 ms. About a week later, he ambushed me again after class and showed me what he had done. First, he used the very clever algorithm from the APL program and coded it in PL/I. Took over a second. Next he wrote a PL/I null program that still took 99 ms to run. (He said: "So you made a pretty safe bet." Me: "Did you think I didn't know that?" Next he created an APL workspace that closed itself immediately: 19 ms. Hmmm. So he rewrote the code in IBM 370 assembler, and did a very good job: 233 ms. Hmmm. Hmmm! What was going on? I explained that the IBM 3033 had build in a special accelerator for APL code, instructions that could not be generated by the assembler. This set included some vector operations which were very fast when just moving bits around, arithmetic was still limited by the ALU bottleneck. Since the magic square algorithm used only array permutations, it was very, very fast. Now this is a pretty special case, but in general modern processors have hundreds of special purpose operations which are not available from the assembler. This is because the Assembler limits itself to the set of instructions specified for all the implementations of the architecture. For example, on Sun SPARCs, at first it was the case that you could use (integer) multiply and divide operations which weren't available in compiler generated code, but could be generated by the assembler. Then it was possible to provide (in Ada terms) code inserts that generated these instructions. Then the compilers started generating them. Next the OS provided routines which trapped the instructions if not provided by the particular chip you were running on, etc. But about when the version 8 SPARC reference came out, things proceded in exactly the reverse order with some of the new instructions: the assembler was the last to support them. (I could go into details, but there were serious timing issues for these instructions, and it ws thought that they would only be used in compiler run-times for special purposes.) So for a while, I had some Ada code for the SPARC that ran faster than the tightest assembler I could write. Currently we are in this regime again. The Intel Pentium II & III and the Athelon processor have different graphics support enhancements. We could argue which is better, but using special libraries and run-times, in some cases special to both the chip AND the graphics card, you can generate code which is significantly faster than any Pentium assembly code. Of course, to get these advantages, not only do you have to have processor specific knowledge, but you often have to be able to program in machine language, and that is very definitely a dying art. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-12-01 0:00 ` Robert I. Eachus @ 1999-12-02 0:00 ` Larry Kilgallen 1999-12-02 0:00 ` Robert I. Eachus 1999-12-03 0:00 ` Robert Dewar 1 sibling, 1 reply; 50+ messages in thread From: Larry Kilgallen @ 1999-12-02 0:00 UTC (permalink / raw) In article <3845D4B4.98354460@mitre.org>, "Robert I. Eachus" <eachus@mitre.org> writes: > Now this is a pretty special case, but in general modern processors > have hundreds of special purpose operations which are not available from > the assembler. This is because the Assembler limits itself to the set > of instructions specified for all the implementations of the > architecture. For example, on Sun SPARCs, at first it was the case that > you could use (integer) multiply and divide operations which weren't > available in compiler generated code, but could be generated by the > assembler. Then it was possible to provide (in Ada terms) code inserts > that generated these instructions. Then the compilers started > generating them. Next the OS provided routines which trapped the > instructions if not provided by the particular chip you were running on, > etc. But about when the version 8 SPARC reference came out, things > proceded in exactly the reverse order with some of the new instructions: > the assembler was the last to support them. (I could go into details, > but there were serious timing issues for these instructions, and it ws > thought that they would only be used in compiler run-times for special > purposes.) So for a while, I had some Ada code for the SPARC that ran > faster than the tightest assembler I could write. > > Currently we are in this regime again. The Intel Pentium II & III > and the Athelon processor have different graphics support enhancements. > We could argue which is better, but using special libraries and > run-times, in some cases special to both the chip AND the graphics card, > you can generate code which is significantly faster than any Pentium > assembly code. Let me give a counter-example. Macro-64 on Alpha VMS certainly does not contain anything specific to versions of the architecture not yet designed :-), but it does allow you to specify your own instruction definitions, so any possible bit combination for an instruction is attainable. Larry Kilgallen ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-12-02 0:00 ` Larry Kilgallen @ 1999-12-02 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 50+ messages in thread From: Robert I. Eachus @ 1999-12-02 0:00 UTC (permalink / raw) Larry Kilgallen wrote: > Let me give a counter-example. Macro-64 on Alpha VMS certainly does > not contain anything specific to versions of the architecture not yet > designed :-), but it does allow you to specify your own instruction > definitions, so any possible bit combination for an instruction is > attainable. And the original assembler for the PDP-1, not only allowed you to do this, but I have a copy of some code arond here somewhere which not only did this, but used it to call instructions I had added to a particular PDP-1. (Actually, the PDP-1 MACRO assembler was so powerful that the PDP-6 MACRO assembler was originally writen using it.) The PDP-11/60, and I think some other PDP-11 models had user programmable microcode so that you didn't have to modify the hardware to add your favorite instructions. I've also had compilers generate self-modifying code. For example, the code includes jumps to run-time routines to do integer multiply and divide, but if this machine has hardware to do those, then the run-time routine back-patches the executable image so that it is not called again. All very fancy tricks, but sort of beside the point, but your mention of Macro-64 brought back memories... In any case, I think that Robert Dewar's position is an expert programmer can do anything that the compiler can do--after all if it is in the compiler someone had to think of it first. So such a programmer can always do better than the compiler. However, I have run into several counterexamples. My favorite came during the early days of Ada. A programmer--I'll call him Joe--called up and said that our compiler was generating incorrect code, so I asked him to send me the source. After studying his over a page long example for a while, I called back and suggested a two line replacement. His incredulous comment was, "You can do that in Ada?" He promised to call me back if it didn't work. A few minutes later, he called back. "I get exactly the same code," he said, "and you can't do that in three instructions--it takes four." So I printed an assembly listing and looked at it. "Looks perfectly fine to me. The first instruction reads the offset from the first argument on the stack and post-decrements the stack pointer. The second instruction indirects through the second argument on the stack, adding the offset it just read into a register. The third instruction preincrements the stack pointer, and then returns." Joe was flabergasted. He went off to check, and sure enough the compiler generated code did beat the code he had discovered years earlier. I agree, never in a million years would I have thought of post-incrementing and pre-incrementing the stack pointer, especially in the RETURN instruction, but it was legal. And since the index had been statically verified, there was no concern about an exception occuring in the middle. Score one for peephole optimization. This was on Honeywell equipment, but the BLISS-11 compiler had a peephole optimizer that was even more agressive, but could take hours to compile a few lines of code. (Yes, the process was NP-time, but it was usually only used on tight loops and on frequently called routines that were part of the operating system or compiler run-times.) Using BLISS-11 on such inner loops, I was amazed at how often it discovered tricks that I would never have thought of. (For those unfamiliar with the PDP series of machines, the PDP-1 was an 18-bit single address architecture, the PDP-11 was a 16-bit two (register) address architecture using a register array, and the PDP-6, with 36-bit word and 15-bit addresses had a mix, mostly one-address instructions, with some two address instructions, some one plus register, some two register instructions, and finally a couple of two address conditional branches.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-12-01 0:00 ` Robert I. Eachus 1999-12-02 0:00 ` Larry Kilgallen @ 1999-12-03 0:00 ` Robert Dewar 1999-12-03 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 50+ messages in thread From: Robert Dewar @ 1999-12-03 0:00 UTC (permalink / raw) In article <3845D4B4.98354460@mitre.org>, "Robert I. Eachus" <eachus@mitre.org> wrote: > I could go into details, Please at least give references! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-12-03 0:00 ` Robert Dewar @ 1999-12-03 0:00 ` Robert I. Eachus 1999-12-06 0:00 ` Robert Dewar 0 siblings, 1 reply; 50+ messages in thread From: Robert I. Eachus @ 1999-12-03 0:00 UTC (permalink / raw) Robert Dewar wrote: > > I could go into details, > Please at least give references! Do you have copies of the SPARC architecture Versions 7 and 8? There were many instructions added to version 8 of the architecture. Even though not all existing SPARC processors supported them directly, version 8 added a number of instructions not in version 7. To comple with version 8 (and now version 9) of the reference manual, you had to support these instructions in a trap handler if they were not supported by the processor. There was a window where SunOS did not support the new instructions-- even by emulation. In fact the SunAda(VADS) 1.x compiler did not even allow these instructions in code inserts. However, I was able to create a package that contained "legitmate" implementations of these instructions and then edit the binary to use the new instructions. I couldn't use pragma INLINE on the operations, but when these functions were called the only overhead incurred was a function call rather than a call to a run-time routine that simulated integer multiplication and division. Of course I could and did override the Standard operators in the body of the using packages. As you know, SPARC subroutine calls are very efficient when everything can be done without creating an new stack frame. So I could get a several fold speed increase over asm writing in Ada. This was very handy when I was working on multi-precision arithmetic, prime numbers, and random number generators. One particularly useful pair of instructions did 32x32-->64 bit multiplies and 64/32-->32,32 divides. Of course, you had to be very careful since the Y register had a long latency on loads and stores from other registers. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-12-03 0:00 ` Robert I. Eachus @ 1999-12-06 0:00 ` Robert Dewar 1999-12-13 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 50+ messages in thread From: Robert Dewar @ 1999-12-06 0:00 UTC (permalink / raw) In article <38482436.F6F36E5@mitre.org>, "Robert I. Eachus" <eachus@mitre.org> wrote: > Robert Dewar wrote: > > > I could go into details, > > > Please at least give references! > > Do you have copies of the SPARC architecture Versions 7 > and 8? Yes, of course, what has this to do with special instructions on IBM main frames to speed up APL (that is what I understood you to be talking about???) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-12-06 0:00 ` Robert Dewar @ 1999-12-13 0:00 ` Robert I. Eachus 1999-12-13 0:00 ` carr_tom 1999-12-19 0:00 ` Robert Dewar 0 siblings, 2 replies; 50+ messages in thread From: Robert I. Eachus @ 1999-12-13 0:00 UTC (permalink / raw) Robert Dewar wrote: > Yes, of course, what has this to do with special instructions > on IBM main frames to speed up APL (that is what I understood > you to be talking about???) Oh, well if you wanted references to that, look at the IBM pricing schedules for the IBM 3033 series, although the same feature was available on other 370 series processors. But the basic issue is that there are instructions not part of the instruction set on many processors, and compiler run-times often take advantage of these features (in some cases, of necessity), while the standard assembler for the platform has little or no support for the same. While we are on the subject of the 370 architecture, another "art form" was to program channel controllers. I remember one matrix multiplying routine for the 360/370 series which used the paging controller for the swap disks to transpose matrices. (Darn! What was the name of the U. Michigan OS? Not MAD that was much earlier. Was it MTDS?) Anyway, since we used drums instead of disks for swapping, the code needed a bit of massaging, which was how I ran into it. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-12-13 0:00 ` Robert I. Eachus @ 1999-12-13 0:00 ` carr_tom 1999-12-17 0:00 ` Robert I. Eachus 1999-12-19 0:00 ` Robert Dewar 1 sibling, 1 reply; 50+ messages in thread From: carr_tom @ 1999-12-13 0:00 UTC (permalink / raw) "Robert I. Eachus" <eachus@mitre.org> writes: > While we are on the subject of the 370 architecture, another "art >form" was to program channel controllers. I remember one matrix >multiplying routine for the 360/370 series which used the paging >controller for the swap disks to transpose matrices. (Darn! What was >the name of the U. Michigan OS? Not MAD that was much earlier. Was it >MTDS?) Anyway, since we used drums instead of disks for swapping, the >code needed a bit of massaging, which was how I ran into it. >-- I remember Michigan Terminal System (MTS) from the 1970's. Was that the one you were thinking of? /Tom -- Thomas Peter Carr | I have a dream, ... carr_tom@si.com (Internet) | M L King Jr 08/28/63 616-241-8846 / 616-241-7533 FAX (Telephone) | Smiths Industries, MS 3D1; 3290 Patterson Ave SE; Grand Rapids, MI 49512-1991 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-12-13 0:00 ` carr_tom @ 1999-12-17 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 50+ messages in thread From: Robert I. Eachus @ 1999-12-17 0:00 UTC (permalink / raw) carr_tom wrote: > I remember Michigan Terminal System (MTS) from the 1970's. Was that the > one you were thinking of? Yep. I used it and did some support at RPI. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-12-13 0:00 ` Robert I. Eachus 1999-12-13 0:00 ` carr_tom @ 1999-12-19 0:00 ` Robert Dewar 1999-12-21 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 50+ messages in thread From: Robert Dewar @ 1999-12-19 0:00 UTC (permalink / raw) In article <38555F1D.FBA187A4@mitre.org>, "Robert I. Eachus" <eachus@mitre.org> wrote: > Robert Dewar wrote: > > > Yes, of course, what has this to do with special instructions > > on IBM main frames to speed up APL (that is what I understood > > you to be talking about???) > > Oh, well if you wanted references to that, look at the IBM pricing > schedules for the IBM 3033 series, although the same feature was > available on other 370 series processors. I have the Pops for the 3033, and I still do not know what you are talking about, please refer to the exact instructions you are referring to, thanks! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-12-19 0:00 ` Robert Dewar @ 1999-12-21 0:00 ` Robert I. Eachus 1999-12-23 0:00 ` Robert Dewar 0 siblings, 1 reply; 50+ messages in thread From: Robert I. Eachus @ 1999-12-21 0:00 UTC (permalink / raw) Robert Dewar wrote: > I have the Pops for the 3033, and I still do not know what > you are talking about, please refer to the exact instructions > you are referring to, thanks! I am not referring to any instructions because they were undocumented! You should see in the 3033 documentation that there were several microcode extensions included in the base price, including the one for APL support. It was an optional add-on for many of the 370 series machines, including I think the 3031 and 3032, but was standard on the 3033. With the extensions, benchmarking APL vs. Fortran or PL/I usually resulted in a significant win for using APL. In fact, many significant systems used by the airline industry were written in APL by I. P. Sharp because it was significantly faster than any other language on high-end IBM mainframes. I did a lot of number-crunching on the 3033, and most matrix operations were much faster in APL than using specialized statistics packages from Fortran. (Note: I didn't care as much about speed as about accuracy. The APL domino operator was better for matrix inversion--and linear equation solving--than several of the statistics packages, and most especially on stiff or ill-formed matrices.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-12-21 0:00 ` Robert I. Eachus @ 1999-12-23 0:00 ` Robert Dewar 1999-12-23 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 50+ messages in thread From: Robert Dewar @ 1999-12-23 0:00 UTC (permalink / raw) In article <385FF32A.6D5302F5@mitre.org>, "Robert I. Eachus" <eachus@mitre.org> wrote: > Robert Dewar wrote: > > > I have the Pops for the 3033, and I still do not know what > > you are talking about, please refer to the exact instructions > > you are referring to, thanks! > > I am not referring to any instructions because they were > undocumented! You should see in the 3033 documentation that there were > several microcode extensions included in the base price, including the > one for APL support. It was an optional add-on for many of the 370 > series machines, including I think the 3031 and 3032, but was standard > on the 3033. I really would like to see a definitive reference for this. I cannot find any evidence that the above claim is true, and I have a lot of IBM documentation from that period! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-12-23 0:00 ` Robert Dewar @ 1999-12-23 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 50+ messages in thread From: Robert I. Eachus @ 1999-12-23 0:00 UTC (permalink / raw) Robert Dewar wrote: > I really would like to see a definitive reference for this. I > cannot find any evidence that the above claim is true, and I > have a lot of IBM documentation from that period! I'm a pack rat, but not quite that much of a pack rat. When RPI was upgrading from an IBM 360/50, the committee looked at several alternatives. IBM was almost ruled out until we got to run some benchmarks on the prototype 3033. We then ordered one on the first day orders were accepted and then traded with someone whose building wasn't ready to get a very low serial number machine. (Our new building wasn't ready either, but there was room to shoehorn it in with the 360/50.) In any case, there were several microcode extensions which, when used, dramatically sped up some of our key benchmarks. Anyone from IBM--or a bigger packrat than I am--who can find a twenty year old price list? -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-25 0:00 ` Robert Dewar 1999-11-25 0:00 ` Peter Milliken @ 1999-11-26 0:00 ` Vladimir Olensky 1999-11-26 0:00 ` Robert Dewar 1 sibling, 1 reply; 50+ messages in thread From: Vladimir Olensky @ 1999-11-26 0:00 UTC (permalink / raw) Robert Dewar wrote in message <81k67s$47l$1@nnrp1.deja.com>... >In article <slrn83ptfb.kn.lutz@taranis.iks-jena.de>, > lutz@iks-jena.de (Lutz Donnerhacke) wrote: >> The common experience is, that high level languages result in >> slow and bloated code. But this must not be true. There is no >> reason for such compilers despite laziness of developers (it's >> an expensive development). [..] >Certainly if you write Ada carefully using GNAT, you will get >perfectly efficient code ... I'd like to confirm that if GNAT is used carefully then in many cases one could obtain up to (90-95)% efficiency compared with what one could squeeze out using assembler. If not carefully than result could be (20-40)% for both GNAT and OA. Not recently I did a small investigation regarding this issue. There are of course some special cases when using assembler one can easily outperform GNAT in up to 8 times on the IA32 platform but I think that next GNAT releases will leave no such opportunities. I think it is quite obvious what these cases are :-). Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-26 0:00 ` Vladimir Olensky @ 1999-11-26 0:00 ` Robert Dewar 1999-11-26 0:00 ` Vladimir Olensky 0 siblings, 1 reply; 50+ messages in thread From: Robert Dewar @ 1999-11-26 0:00 UTC (permalink / raw) In article <s3rhigaqa4r69@corp.supernews.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > There are of course some special cases when using assembler > one can easily outperform GNAT in up to 8 times on the IA32 > platform but I think that next GNAT releases will leave no > such opportunities. I think it is quite obvious what these > cases are :-). I have no idea what Vladimir is talking about here. There are certainly cases where GNAT, like all other compilers I know of does not generate optimal code, but a) I do not know of specific cases that Vladimir is talking of b) No one around here would claim that all such cases will be removed in the next release! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-26 0:00 ` Robert Dewar @ 1999-11-26 0:00 ` Vladimir Olensky 1999-11-27 0:00 ` Robert Dewar 0 siblings, 1 reply; 50+ messages in thread From: Vladimir Olensky @ 1999-11-26 0:00 UTC (permalink / raw) Robert Dewar wrote in message <81m3a5$blp$1@nnrp1.deja.com>... >In article <s3rhigaqa4r69@corp.supernews.com>, > "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: >> There are of course some special cases when using assembler >> one can easily outperform GNAT in up to 8 times on the IA32 >> platform but I think that next GNAT releases will leave no >> such opportunities. I think it is quite obvious what these >> cases are :-). > >I have no idea what Vladimir is talking about here. There are >certainly cases where GNAT, like all other compilers I know >of does not generate optimal code, but > >a) I do not know of specific cases that Vladimir is talking of I thought that "up to 8 times on the IA32 platform" is a good hint. As I mentioned GNAT is very effective when used carefully (much more effective than for example OA educational version that does not provide any optimization options) I was talking about IA32 ++ architecture features that are not directly supported by GNAT yet. These features are SIMD IA32 extensions (Single Instruction Multiple Data) . Right now they are accessible only by using assembler (but may be I do not know something ???). Operations on vectors of bytes are eight times faster as such operations are done in parallel on eight bytes in a single instruction. These IA32 SIMD extensions also provide direct support for saturated arithmetic which is very interesting option as well. I have in my plans to create small Ada package for saturated arithmetic making use this features in some near future. >b) No one around here would claim that all such cases will be > removed in the next release! I just expressed hope that may be in the next release or next after next or some time in the future GNAT would have direct IA32++ SIMD support. (I wrote releases but not release). So I was talking about adding and not removing. But may be it is better not to spent time on this but focus on IA64 architecture that offer much more advanced features. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-26 0:00 ` Vladimir Olensky @ 1999-11-27 0:00 ` Robert Dewar 1999-11-28 0:00 ` Vladimir Olensky 0 siblings, 1 reply; 50+ messages in thread From: Robert Dewar @ 1999-11-27 0:00 UTC (permalink / raw) In article <s3ti5n1a4r24@corp.supernews.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > These IA32 SIMD extensions ... Well I doubt there are many Ada programs which would be affected here, these instructions are unlikely to be very useful in the context of general purpose Ada code. I believe that GCC 3.0 will make some attempt to use these instructions, but my guess is that most Ada programs will not notice the difference. This is certainly not one of the most important targets of opportunity for improving the quality of GNAT code on the ia32 :-) Actually I think most programs will see FAR more gain from the general improvement in ia32 code that has come from rewriting the ia32 config file. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-27 0:00 ` Robert Dewar @ 1999-11-28 0:00 ` Vladimir Olensky 0 siblings, 0 replies; 50+ messages in thread From: Vladimir Olensky @ 1999-11-28 0:00 UTC (permalink / raw) Robert Dewar wrote in message <81nmkf$dvp$1@nnrp1.deja.com>... >In article <s3ti5n1a4r24@corp.supernews.com>, > "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: >> These IA32 SIMD extensions ... > >Well I doubt there are many Ada programs which would be >affected here, these instructions are unlikely to be very >useful in the context of general purpose Ada code. [...] >This is certainly not one of the most important targets >of opportunity for improving the quality of GNAT code on >the ia32 :-) Hmm, you mean that general purpose Ada does not require ability to efficiently process data which length is more than some small amount of bytes and if someone wants efficiency in this area than one should use Assembler or Intel C instead ?-) Efficient data processing is not in the domain of general purpose Ada programming ??? Or no one wants efficient data processing on IA32 platform ??? That's very interesting point of view :-) Just consider data encryption and decryption which is becoming more and more important. There are a lot of other general purpose things that require efficient data processing. > I believe that GCC 3.0 will make some attempt to use these >instructions, Probably it will happen at some time. Here is a quote from GCC page: " The PentiumGCC (short PGCC) is an extension of GCC specifically aimed at the newer Intel chips and their clones (Pentium, PPro, Pentium-II and the Cyrix6x86 and AMD-K6+ chips). The current goal is to enhance GCC to a point where it generates code as fast as PGCC, but until that work is finished PGCC is still maintained, and often achieves substantial speed improvements over GCC" > but my guess is that most Ada programs will not > notice the difference. If GNAT won't use that improvements :-) >Actually I think most programs will see FAR more gain from the >general improvement in ia32 code that has come from rewriting >the ia32 config file. Here I agree that general improvement in ia32 code is very important from all points of view and it is always very welcomed. There still exist some silly pieces of code generated by the compiler that is not possible to improve with any of the existing optimization options. In other thread Robert C. Leif did a very good comparison with the chess game ( I always thought the same :-). When compiler will be able to analyze ahead more than one or two movements of the player (programmer) than situation would be much better. May be compiler implementators should ask Garry Kasparov to help them ? -) ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-24 0:00 Compiler for Z80/6510 Lutz Donnerhacke 1999-11-24 0:00 ` Wil @ 1999-11-24 0:00 ` Frank Klemm 1999-11-24 0:00 ` Lutz Donnerhacke 1999-11-24 0:00 ` Tucker Taft 1999-11-29 0:00 ` Marin Condic 3 siblings, 1 reply; 50+ messages in thread From: Frank Klemm @ 1999-11-24 0:00 UTC (permalink / raw) On 24 Nov 1999 09:05:40 GMT, Lutz Donnerhacke <lutz@iks-jena.de> wrote: >Does anyone know a working Ada95 compiler for Z80 (U880) and 6510/6502 >microcontrollers? > Do you want a Ada Compiler on a Z80/6502/6510 based system (huch?) or a Ada Crosscompiler for the target Z80/6502/6510 ? -- Frank Klemm ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-24 0:00 ` Frank Klemm @ 1999-11-24 0:00 ` Lutz Donnerhacke 0 siblings, 0 replies; 50+ messages in thread From: Lutz Donnerhacke @ 1999-11-24 0:00 UTC (permalink / raw) * Frank Klemm wrote: >On 24 Nov 1999 09:05:40 GMT, Lutz Donnerhacke <lutz@iks-jena.de> wrote: >>Does anyone know a working Ada95 compiler for Z80 (U880) and 6510/6502 >>microcontrollers? >Do you want a Ada Compiler on a Z80/6502/6510 based system (huch?) >or a Ada Crosscompiler for the target Z80/6502/6510 ? With the latter one, the first one can be compiled ;-) Of course, I'm interested in a cross compiler. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-24 0:00 Compiler for Z80/6510 Lutz Donnerhacke 1999-11-24 0:00 ` Wil 1999-11-24 0:00 ` Frank Klemm @ 1999-11-24 0:00 ` Tucker Taft 1999-11-29 0:00 ` Marin Condic 3 siblings, 0 replies; 50+ messages in thread From: Tucker Taft @ 1999-11-24 0:00 UTC (permalink / raw) Lutz Donnerhacke wrote: > > Does anyone know a working Ada95 compiler for Z80 (U880) and 6510/6502 > microcontrolers? We have a validated Ada 95 compiler that uses optimized ANSI C as its intermediate language. The compiler was designed with targets like microcontrollers in mind. For space reasons, you would probably want to avoid parts of the Ada RTS, but you could write in an appropriately restricted subset of your choosing. If you are interested in this technology, please let us know. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-24 0:00 Compiler for Z80/6510 Lutz Donnerhacke ` (2 preceding siblings ...) 1999-11-24 0:00 ` Tucker Taft @ 1999-11-29 0:00 ` Marin Condic 1999-11-29 0:00 ` Lutz Donnerhacke ` (3 more replies) 3 siblings, 4 replies; 50+ messages in thread From: Marin Condic @ 1999-11-29 0:00 UTC (permalink / raw) Lutz Donnerhacke wrote: > Does anyone know a working Ada95 compiler for Z80 (U880) and 6510/6502 > microcontrolers? It's pretty sad that there was a near zero useful response to this question. (The most useful being from Tucker Taft regarding the Ada-toC compiler). This so quickly degenerated into a discussion about Ada vs Assembler that one wonders if maybe this is a smoke screen to cover up the embarrassing real answer that "No. There are no Ada compilers for small microcontrollers." To the best of my knowledge, this is a true statement - I've asked the question myself many times and I would *love* to be told that I'm wrong and here's the compiler to prove it. You will find any number of people who will tell you how there is no theoretical roadblock to making such a compiler. However, when you get around to saying "Show me one" the subject seems to quickly change to something like instruction set architectures, the relative efficiency of assembly programming or why C sucks. It must be too difficult/expensive to do for the perceived size of the market or somebody would have retargeted their compiler by now and started hawking it in conjunction with a microcontroller. I think it would be very useful to have a microcontroller card with an Ada compiler targeted to it, hosted on a PC and at an affordable price. I think that as a package, it would do much to promote Ada within the embedded programming world. One successful development could sell hundreds-of-thousands of the microcontroller card and generate a royalty for the RTK for the compiler. (Sort of like cutting a hit record and watching it go platinum!) The sad news is that while you can find dozens of off the shelf controller cards with a whole kit for developing the software in C from a PC, (and generally under $500, so a garage startup can afford the development kit!) you won't likely find anything similar in Ada. If you do, I'd be most grateful to hear about it. MDC -- Marin David Condic Only two more days and this address is defunct! See my web page if you want to contact me...: Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-29 0:00 ` Marin Condic @ 1999-11-29 0:00 ` Lutz Donnerhacke 1999-11-29 0:00 ` Marin Condic 1999-11-29 0:00 ` Mike Silva ` (2 subsequent siblings) 3 siblings, 1 reply; 50+ messages in thread From: Lutz Donnerhacke @ 1999-11-29 0:00 UTC (permalink / raw) * Marin Condic wrote: >Lutz Donnerhacke wrote: >> Does anyone know a working Ada95 compiler for Z80 (U880) and 6510/6502 >> microcontrolers? > >It's pretty sad that there was a near zero useful response to this >question. (The most useful being from Tucker Taft regarding the Ada-toC >compiler). This so quickly degenerated into a discussion about Ada vs >Assembler that one wonders if maybe this is a smoke screen to cover up the >embarrassing real answer that "No. There are no Ada compilers for small >microcontrollers." That's not true. I got a partial offer for a cross compiler. Thanx to this company. >I think it would be very useful to have a microcontroller card with an Ada >compiler targeted to it, hosted on a PC and at an affordable price. The price is affordable, but we need it for pure non commercial projects like reprogramming a Gameboy and doing some hacking (http://gsho.thur.de/) >The sad news is that while you can find dozens of off the shelf controller >cards with a whole kit for developing the software in C from a PC, (and >generally under $500, so a garage startup can afford the development kit!) >you won't likely find anything similar in Ada. If you do, I'd be most >grateful to hear about it. C Compilers can be made easily. The code generation is as expected: Bad. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-29 0:00 ` Lutz Donnerhacke @ 1999-11-29 0:00 ` Marin Condic 1999-11-29 0:00 ` Lutz Donnerhacke 0 siblings, 1 reply; 50+ messages in thread From: Marin Condic @ 1999-11-29 0:00 UTC (permalink / raw) To: Lutz Donnerhacke Lutz Donnerhacke wrote: > That's not true. I got a partial offer for a cross compiler. Thanx to this > company. > Which company? > > >I think it would be very useful to have a microcontroller card with an Ada > >compiler targeted to it, hosted on a PC and at an affordable price. > > The price is affordable, but we need it for pure non commercial projects > like reprogramming a Gameboy and doing some hacking (http://gsho.thur.de/) > I'm looking at the web site. Unfortunately, I do not understand German. Is this site offering an Ada cross compiler for their microcontroller? > > C Compilers can be made easily. The code generation is as expected: Bad. That tends to depend a lot on the compiler. Some are substantially better than others. The key feature being that at least you can find a C compiler for a microcontroller. You might want to look at: http://www.zworld.com/ They have some spiffy little controller cards and development kits available. MDC -- Marin David Condic Only two more days and this address is defunct! See my web page if you want to contact me...: Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-29 0:00 ` Marin Condic @ 1999-11-29 0:00 ` Lutz Donnerhacke 0 siblings, 0 replies; 50+ messages in thread From: Lutz Donnerhacke @ 1999-11-29 0:00 UTC (permalink / raw) * Marin Condic wrote: >Lutz Donnerhacke wrote: >> That's not true. I got a partial offer for a cross compiler. Thanx to this >> company. > >Which company? They can write thereself if they want. I'm feeling bad in publishing private discussions. >> >I think it would be very useful to have a microcontroller card with an Ada >> >compiler targeted to it, hosted on a PC and at an affordable price. >> >> The price is affordable, but we need it for pure non commercial projects >> like reprogramming a Gameboy and doing some hacking (http://gsho.thur.de/) > >I'm looking at the web site. Unfortunately, I do not understand German. Is >this site offering an Ada cross compiler for their microcontroller? They do smartcard hacking. They need one. At the moment the stick to assembly. >> C Compilers can be made easily. The code generation is as expected: Bad. > >That tends to depend a lot on the compiler. Some are substantially better than >others. The key feature being that at least you can find a C compiler for a >microcontroller. But's sensless. Luckily I'm not involved in a DSP programming project where { int i = 2; i++; } can result in 2 or 4 due to missing multithreading features and really bad assember output. A the moment there is a main routine consuming more than 700k bytes of code as a single routine (partial compiled with a lot of #ifdef orgies). Over 80% of the source are coded in assembler directly to make use of EXCHanging opcodes in order to work with a semaphore. *Argl* That's horrible. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-29 0:00 ` Marin Condic 1999-11-29 0:00 ` Lutz Donnerhacke @ 1999-11-29 0:00 ` Mike Silva 1999-11-29 0:00 ` Marin Condic 1999-11-29 0:00 ` Robert C. Leif, Ph.D. 1999-12-01 0:00 ` Robert Dewar 3 siblings, 1 reply; 50+ messages in thread From: Mike Silva @ 1999-11-29 0:00 UTC (permalink / raw) Marin Condic wrote in message <3842C8FD.5EFB9685@pwfl.com>... >...the >embarrassing real answer that "No. There are no Ada compilers for small >microcontrollers." My own instinct (meaning I'm not prepared to back it up, just wave my arms <g>) on this is that (1) for the 8-bit world, the chips really are too small to support enough Ada to be significant, (2) for the 16-bit world, full Ada could be supported, but the 16-bit world seems to be turning into something of a backwater (once you've gone that far, especially with >16 bit addresses, why not go 32 bits internally?), leaving (3) the 32-bit world, where Ada, it seems to me, has an excellent chance to be "rehabilitated" as the percentage of embedded systems that go 32-bit will just continue to climb. IMHO, Ada on cheap 32-bit hardware is an embedded designer's dream come true -- it's just tooooo delicious! Mike ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-29 0:00 ` Mike Silva @ 1999-11-29 0:00 ` Marin Condic 1999-11-29 0:00 ` John Duncan ` (2 more replies) 0 siblings, 3 replies; 50+ messages in thread From: Marin Condic @ 1999-11-29 0:00 UTC (permalink / raw) To: Mike Silva Mike Silva wrote: > where Ada, it seems to me, has an excellent chance to be "rehabilitated" as > the percentage of embedded systems that go 32-bit will just continue to > climb. IMHO, Ada on cheap 32-bit hardware is an embedded designer's dream > come true -- it's just tooooo delicious! Agreed and very true. Anyone who has ever tried to squeeze software into a tiny address space can understand why 32 bit hardware is a very welcome gift to the software designer. I would point out that there still may be lots of reasons why the 16 bit processors will continue to have a large segment of the market. Not all applications need the power or space of a 32 bit architecture, so you are at risk of overdesigning. (The proverbial Brick Outhouse) If there is any cost differential at all, this becomes significant over a large production run. So long as a 16 bit controller can be built for even a few cents less than a 32 bit controller, there is an advantage to going this route. (True also of the 8 bit world vs 16 bit, which is why they are still with us.) You also have a lot of compatibility issues which may come into play. Just because you can build a bigger, faster, better 32 bit computer doesn't mean it will plug into the slot where you previously had a 16 bit machine. Do you redesign the automobile, industrial robot, radar controller, etc., to use a 32 bit processor if the 16 bit machine can still do the job? To go in your direction, how about this? Produce a PowerPC based circuit board with a few A/D and/or F/D converters, some discrete lines, maybe a UART and some other stuff that would make it a good controller and bundle that with an Ada compiler, link/load/diagnostic tools, etc. all plugged into a PC for development. Think that could be done for ~ $500? What do you imagine the minimum production price of a PowerPC based SBC could be in some reasonable volume? MDC -- Marin David Condic Only two more days and this address is defunct! See my web page if you want to contact me...: Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-29 0:00 ` Marin Condic @ 1999-11-29 0:00 ` John Duncan 1999-11-30 0:00 ` Lutz Donnerhacke 1999-11-29 0:00 ` Mike Silva 1999-11-30 0:00 ` Tarjei Jensen 2 siblings, 1 reply; 50+ messages in thread From: John Duncan @ 1999-11-29 0:00 UTC (permalink / raw) > To go in your direction, how about this? Produce a PowerPC based circuit board > with a few A/D and/or F/D converters, some discrete lines, maybe a UART and some > other stuff that would make it a good controller and bundle that with an Ada > compiler, link/load/diagnostic tools, etc. all plugged into a PC for > development. Think that could be done for ~ $500? What do you imagine the > minimum production price of a PowerPC based SBC could be in some reasonable > volume? > I could see it being done with a MIPS R4300i. They are like $30/chip. Toss in GNAT, and you have a good system. Plus, since there is so much optimization work targeted at the MIPS, it'd be good. Actually, Nintendo sells a box with an advanced graphics controller, four digital inputs, a memory card interface, sound, NTSC output, etc., and a MIPS R4300i, for around $99, but the C/C++ compiler and development kit (Metrowerks) are rather expensive. :) Still, the price is low enough to show what can be done. :) -John ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-29 0:00 ` John Duncan @ 1999-11-30 0:00 ` Lutz Donnerhacke 0 siblings, 0 replies; 50+ messages in thread From: Lutz Donnerhacke @ 1999-11-30 0:00 UTC (permalink / raw) * John Duncan wrote: >I could see it being done with a MIPS R4300i. They are like $30/chip. Toss >in GNAT, and you have a good system. Plus, since there is so much >optimization work targeted at the MIPS, it'd be good. If you can: Fine. I can not choose my target. I have a 65c02, a U880 (Z80) and 8051 (sic!) to support. Especially the 8051 can not be exchanges despite somebody find a way to get R4000 chips to work on a smart card. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-29 0:00 ` Marin Condic 1999-11-29 0:00 ` John Duncan @ 1999-11-29 0:00 ` Mike Silva 1999-11-30 0:00 ` Tarjei Jensen 2 siblings, 0 replies; 50+ messages in thread From: Mike Silva @ 1999-11-29 0:00 UTC (permalink / raw) Marin Condic wrote in message <3842E10D.5AE759FE@pwfl.com>... >... >I would point out that there still may be lots of reasons why the 16 bit >processors will continue to have a large segment of the market. Not all >applications need the power or space of a 32 bit architecture, so you are at >risk of overdesigning. (The proverbial Brick Outhouse) If there is any cost >differential at all, this becomes significant over a large production run. So >long as a 16 bit controller can be built for even a few cents less than a 32 bit >controller, there is an advantage to going this route. (True also of the 8 bit >world vs 16 bit, which is why they are still with us.) Agreed, there are cases where bottom-line hardware costs are overriding. However, there are also cases where other factors are more important, such as availability (the cheapest parts are often the hardest to get), tools (inc. libraries), expandability, etc. Just as 8-bit chips are now often found in "4-bit" applications, I get the feeling that 32-bit chips will fill a lot of "16-bit" applications. Not all, of course, but a lot. Also, for every large-volume application there are lots of small-volume ones where spending a bit more for a Brick Outhouse is a smarter way to go than trying to finely match the requirements to the processor. For fun I just looked at the current EDN micro directory issue. Results: 18 8-bit listings, 11 16-bit listings, 20 32-bit listings, 3 64-bit listings. Anyway, I don't disagree with anything you've said. I just sense that there's a lot more movement in 32-bitters than in 16s, and I think that's good for Ada since it's much better represented in the former. Also, the software written for these 32-bit platforms will naturally be more complicated, and I'd expect that lots of people who "got by" using C on smaller projects will find the "old ways" don't cut it on this larger scale. That more-or-less describes my situation, and that's why I've gravitated to Ada. > >To go in your direction, how about this? Produce a PowerPC based circuit board >with a few A/D and/or F/D converters, some discrete lines, maybe a UART and some >other stuff that would make it a good controller and bundle that with an Ada >compiler, link/load/diagnostic tools, etc. all plugged into a PC for >development. Think that could be done for ~ $500? What do you imagine the >minimum production price of a PowerPC based SBC could be in some reasonable >volume? Don't really know about bundled prices (so much would depend on the cost of the software). I -think- I've seen 386 controllers for under $200 and 486 controllers for under $300, in low volumes, and that's usually with a lot of PC-compatible hardware onboard that many people wouldn't need. Mike ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-29 0:00 ` Marin Condic 1999-11-29 0:00 ` John Duncan 1999-11-29 0:00 ` Mike Silva @ 1999-11-30 0:00 ` Tarjei Jensen 2 siblings, 0 replies; 50+ messages in thread From: Tarjei Jensen @ 1999-11-30 0:00 UTC (permalink / raw) Marin Condic wrote >To go in your direction, how about this? Produce a PowerPC based circuit board >with a few A/D and/or F/D converters, some discrete lines, maybe a UART and some >other stuff that would make it a good controller and bundle that with an Ada >compiler, link/load/diagnostic tools, etc. all plugged into a PC for >development. Think that could be done for ~ $500? What do you imagine the >minimum production price of a PowerPC based SBC could be in some reasonable >volume? I think it would be more realistic with a PC host and a PC/104 target. If one could get RTEMS or something similar running smootly in such an environment it should be easy to sell the developers on Ada. Especially if things works with all the possible combinations; 80386, 80486, Pentium, AMD 6K, etc. Greetings, ^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: Compiler for Z80/6510 1999-11-29 0:00 ` Marin Condic 1999-11-29 0:00 ` Lutz Donnerhacke 1999-11-29 0:00 ` Mike Silva @ 1999-11-29 0:00 ` Robert C. Leif, Ph.D. 1999-12-01 0:00 ` Robert Dewar 3 siblings, 0 replies; 50+ messages in thread From: Robert C. Leif, Ph.D. @ 1999-11-29 0:00 UTC (permalink / raw) To: condicma, comp.lang.ada From: Bob Leif To: Marin David Condic One reasonable approach is to host a Java virtual machine (J code interpreter) on the 8 or 16 bit processor. Then use an Ada J code compiler. On a significant project, this should produce a smaller memory requirement then a regular compiler. If it does not, there are significant design flaws in the J code interpreter. In the real-world, it may be necessary to employ significant restrictions on the Ada compiler and possibly minimize the size of the J code interpreter. I must also add that in the past many microprocessors including the original PC CPU used a 16 bit internal chip with an 8 bit bus. One could replace an 8 bit chip with a 32 bit chip, providing the new chip had the same pinout and could send and read data in the old format. -----Original Message----- From: condicma@bogon.pwfl.com [mailto:condicma@bogon.pwfl.com] Sent: Monday, November 29, 1999 10:42 AM To: comp.lang.ada@ada.eu.org Subject: Re: Compiler for Z80/6510 Lutz Donnerhacke wrote: > Does anyone know a working Ada95 compiler for Z80 (U880) and 6510/6502 > microcontrolers? It's pretty sad that there was a near zero useful response to this question. (The most useful being from Tucker Taft regarding the Ada-toC compiler). This so quickly degenerated into a discussion about Ada vs Assembler that one wonders if maybe this is a smoke screen to cover up the embarrassing real answer that "No. There are no Ada compilers for small microcontrollers." To the best of my knowledge, this is a true statement - I've asked the question myself many times and I would *love* to be told that I'm wrong and here's the compiler to prove it. You will find any number of people who will tell you how there is no theoretical roadblock to making such a compiler. However, when you get around to saying "Show me one" the subject seems to quickly change to something like instruction set architectures, the relative efficiency of assembly programming or why C sucks. It must be too difficult/expensive to do for the perceived size of the market or somebody would have retargeted their compiler by now and started hawking it in conjunction with a microcontroller. I think it would be very useful to have a microcontroller card with an Ada compiler targeted to it, hosted on a PC and at an affordable price. I think that as a package, it would do much to promote Ada within the embedded programming world. One successful development could sell hundreds-of-thousands of the microcontroller card and generate a royalty for the RTK for the compiler. (Sort of like cutting a hit record and watching it go platinum!) The sad news is that while you can find dozens of off the shelf controller cards with a whole kit for developing the software in C from a PC, (and generally under $500, so a garage startup can afford the development kit!) you won't likely find anything similar in Ada. If you do, I'd be most grateful to hear about it. MDC -- Marin David Condic Only two more days and this address is defunct! See my web page if you want to contact me...: Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Compiler for Z80/6510 1999-11-29 0:00 ` Marin Condic ` (2 preceding siblings ...) 1999-11-29 0:00 ` Robert C. Leif, Ph.D. @ 1999-12-01 0:00 ` Robert Dewar 3 siblings, 0 replies; 50+ messages in thread From: Robert Dewar @ 1999-12-01 0:00 UTC (permalink / raw) In article <3842C8FD.5EFB9685@pwfl.com>, condicma@pwflcom wrote: > Lutz Donnerhacke wrote: > > > Does anyone know a working Ada95 compiler for Z80 (U880) and 6510/6502 > > microcontrolers? > > It's pretty sad that there was a near zero useful response to this > question. (The most useful being from Tucker Taft regarding the Ada-toC > compiler). This so quickly degenerated into a discussion about Ada vs > Assembler that one wonders if maybe this is a smoke screen to cover up the > embarrassing real answer that "No. There are no Ada compilers for small > microcontrollers." > > To the best of my knowledge, this is a true statement Well it seems to me that the Intermetrics compiler that generates C is a counter example, assuming you can cough up a C compiler for your microcontroller. It would indeed be easy enough to port GNAT for a small microcontroller for which a GCC port exists (often the case), but so far we have not seen any credible evidence that such a port would make commercial sense. I doubt this situation will change in the forseeable future. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~1999-12-23 0:00 UTC | newest] Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-11-24 0:00 Compiler for Z80/6510 Lutz Donnerhacke 1999-11-24 0:00 ` Wil 1999-11-25 0:00 ` Lutz Donnerhacke 1999-11-25 0:00 ` Robert Dewar 1999-11-25 0:00 ` Peter Milliken 1999-11-26 0:00 ` Tarjei Jensen 1999-11-26 0:00 ` Ed Falis 1999-11-26 0:00 ` Robert C. Leif, Ph.D. 1999-11-27 0:00 ` Florian Weimer [not found] ` <01bf38cb$be9b2b60$022a6282@dieppe> 1999-11-28 0:00 ` Robert Dewar 1999-11-28 0:00 ` Robert A Duff 1999-11-30 0:00 ` Pascal Obry 1999-11-28 0:00 ` Robert Dewar 1999-12-06 0:00 ` Richard D Riehle 1999-11-26 0:00 ` Robert Dewar 1999-11-26 0:00 ` Robert A Duff 1999-11-27 0:00 ` Robert Dewar 1999-12-01 0:00 ` Robert I. Eachus 1999-12-02 0:00 ` Larry Kilgallen 1999-12-02 0:00 ` Robert I. Eachus 1999-12-03 0:00 ` Robert Dewar 1999-12-03 0:00 ` Robert I. Eachus 1999-12-06 0:00 ` Robert Dewar 1999-12-13 0:00 ` Robert I. Eachus 1999-12-13 0:00 ` carr_tom 1999-12-17 0:00 ` Robert I. Eachus 1999-12-19 0:00 ` Robert Dewar 1999-12-21 0:00 ` Robert I. Eachus 1999-12-23 0:00 ` Robert Dewar 1999-12-23 0:00 ` Robert I. Eachus 1999-11-26 0:00 ` Vladimir Olensky 1999-11-26 0:00 ` Robert Dewar 1999-11-26 0:00 ` Vladimir Olensky 1999-11-27 0:00 ` Robert Dewar 1999-11-28 0:00 ` Vladimir Olensky 1999-11-24 0:00 ` Frank Klemm 1999-11-24 0:00 ` Lutz Donnerhacke 1999-11-24 0:00 ` Tucker Taft 1999-11-29 0:00 ` Marin Condic 1999-11-29 0:00 ` Lutz Donnerhacke 1999-11-29 0:00 ` Marin Condic 1999-11-29 0:00 ` Lutz Donnerhacke 1999-11-29 0:00 ` Mike Silva 1999-11-29 0:00 ` Marin Condic 1999-11-29 0:00 ` John Duncan 1999-11-30 0:00 ` Lutz Donnerhacke 1999-11-29 0:00 ` Mike Silva 1999-11-30 0:00 ` Tarjei Jensen 1999-11-29 0:00 ` Robert C. Leif, Ph.D. 1999-12-01 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox