Compiler for Z80/6510

Compiler for Z80/6510

[Lutz Donnerhacke]

Does anyone know a working Ada95 compiler for Z80 (U880) and 6510/6502
microcontrolers?

Re: Compiler for Z80/6510

[Wil]

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

Re: Compiler for Z80/6510

[Lutz Donnerhacke]

* 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.

Re: Compiler for Z80/6510

[Robert Dewar]

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.

Re: Compiler for Z80/6510

[Peter Milliken]

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

Re: Compiler for Z80/6510

[Robert Dewar]

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.

Re: Compiler for Z80/6510

[Robert A Duff]

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

Re: Compiler for Z80/6510

[Robert Dewar]

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.

Re: Compiler for Z80/6510

[Robert I. Eachus]

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...

Re: Compiler for Z80/6510

[Larry Kilgallen]

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

Re: Compiler for Z80/6510

[Robert I. Eachus]

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...

Re: Compiler for Z80/6510

[Robert Dewar]

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.

Re: Compiler for Z80/6510

[Robert I. Eachus]

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...

Re: Compiler for Z80/6510

[Robert Dewar]

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.

Re: Compiler for Z80/6510

[Robert I. Eachus]

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...

Re: Compiler for Z80/6510

[carr_tom]

"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

Re: Compiler for Z80/6510

[Robert I. Eachus]

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...

Re: Compiler for Z80/6510

[Robert Dewar]

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.

Re: Compiler for Z80/6510

[Robert I. Eachus]

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...

Re: Compiler for Z80/6510

[Robert Dewar]

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.

Re: Compiler for Z80/6510

[Robert I. Eachus]

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...

Re: Compiler for Z80/6510

[Ed Falis]

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

RE: Compiler for Z80/6510

[Robert C. Leif, Ph.D.]

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

Re: Compiler for Z80/6510

[Florian Weimer]

"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.

Re: Compiler for Z80/6510

[Robert Dewar]

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.

Re: Compiler for Z80/6510

[Robert A Duff]

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

Re: Compiler for Z80/6510

[Pascal Obry]

[-- 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"

RE: Compiler for Z80/6510

[Robert Dewar]

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.

Re: Compiler for Z80/6510

[Richard D Riehle]

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 

Re: Compiler for Z80/6510

[Tarjei Jensen]

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,

Re: Compiler for Z80/6510

[Vladimir Olensky]

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

Re: Compiler for Z80/6510

[Robert Dewar]

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.

Re: Compiler for Z80/6510

[Vladimir Olensky]

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

Re: Compiler for Z80/6510

[Robert Dewar]

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.

Re: Compiler for Z80/6510

[Vladimir Olensky]

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  ? -)

Re: Compiler for Z80/6510

[Tucker Taft]

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

Re: Compiler for Z80/6510

[Frank Klemm]

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
 

Re: Compiler for Z80/6510

[Lutz Donnerhacke]

* 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.

Re: Compiler for Z80/6510

[Marin Condic]

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/

RE: Compiler for Z80/6510

[Robert C. Leif, Ph.D.]

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/

Re: Compiler for Z80/6510

[Lutz Donnerhacke]

* 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.

Re: Compiler for Z80/6510

[Marin Condic]

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/

Re: Compiler for Z80/6510

[Lutz Donnerhacke]

* 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.

Re: Compiler for Z80/6510

[Mike Silva]

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

Re: Compiler for Z80/6510

[Marin Condic]

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/

Re: Compiler for Z80/6510

[Mike Silva]

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

Re: Compiler for Z80/6510

[John Duncan]

> 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

Re: Compiler for Z80/6510

[Lutz Donnerhacke]

* 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.

Re: Compiler for Z80/6510

[Tarjei Jensen]

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,

Re: Compiler for Z80/6510

[Robert Dewar]

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.