Re: RFC : SOME IDEAS FOR THE APPLE II FPGA'ers

Michael J. Mahon wrote:

I wondered how long it would be before we "hit the wall" and
necessity took over...

The interesting thing now will be to see how long it takes for the next
wall to be hit...

The Digitek company, in the 1960's, wrote FORTRAN compilers for,
initially, minicomputers. Inspired by the SDS 940's POPs, they
designed a compiler using a multi-stack pseudo-machine that could
be either interpreted or macro-expanded into "fast calls" or in-line
code.

After porting a compiler to a new machine, they would run it fully
interpretive, in no more than half the memory of the machine, and
use the other half of the machine's memory for profile counters
for the pseudo instructions.

Then they would mark the *big* peaks for in-line expansion, the
middling peaks for fast call expansion, and the rest for interpretation.

This optimization tool allowed them to make the smallest, fastest
compilers in the world for several years--and it was all based on
being able to fit the compiler into less than half the available
memory!

That's a brilliant piece of engineering, in any time, but especially
for its day... I'll have to learn more about it.

I've always been a fan of that approach myself. It's interesting to see
similar techniques applied in current generation languages. Both Java
and .NET utilise "Hot Spot" compilation, which recompiles the bytecode
the machine code at runtime for heavily frequented codepaths. The net
result is that you achieve virtually identical "perceived" runtime to
machine coding the whole app, at a fraction of the cost.

In essence, it takes Knuths famous quote "Premature optimisation is the
root of all evil" and embodies it in a runtime system.

This is why I loved Apple Pascal so much; I could write applications
using a high level language that had shared libraries, dynamic loading,
etc. and hand craft the critical sections in assembly language. Of
course, most people did/do this with Applesoft, but to me BASIC is
hideous

I've always found syntax + compiler semantics to be quite weak in
catching the interesting errors. It's fine for spelling errors and
the occasional type mismatch, but there are just too many utterances
that are perfectly syntactic, but meaningless:

Absolutely true. If we look at the common errors such type checking is
supposed to solve, for instance, array bounds issues that are so common
in C programs, it becomes obvious in retrospect that the problem was
caused not by lack of typing, but by lack of language features to allow
a succinct idiom. There are plenty of languages out there that are
typeless, but programs written in them don't suffer that failure mode,
since they offer a 'foreach' construct to iterate collections in an
error-free way.

It's interesting to watch at the moment, things moving slowly away from
Java/.NET style VM's towards interpreted languages like Ruby. Why?
Programmer productivity.

I'm actually quite enjoying the change, and about the only thing I miss
about the stronger typing models of Java or C++ is that I now have to
commit a lot more API calls to memory, as the language is typeless and
IDE's/Editors can't autocomplete and hint at method invocations
anywhere near as well.

But then, it's also meant shedding complex tools in favour of the good
old text editor and command line combo, as the heavy tools can no
longer justify there own weight.

In the end, it's a fun journey watching a discipline mature, as long as
you can withstand the bumps in the road along the way :-)

Yes, and a microcosm of life itself. ;-)

Absolutely! And as long as one remembers this the bumps are a source of
amusement rather than frustration ;-)

Matt

.

Relevant Pages

  • Re: "STL from the Ground Up"
    ... high-level intermediate language than can interoperate with many other ... If your language lacks expressive features then you cannot write code ... memory management in comparison. ... Mostly because type errors mean that the programmer and compiler disagree ...
    (comp.programming)
  • Re: Executable Memory in a Driver
    ... >> criminal to expose users to the added bluescreen and security risk. ... In a language that can't access outside an array, ... that doesn't need to move memory. ... > desired in the compiler. ...
    (microsoft.public.development.device.drivers)
  • Re: multiple threads and volatile
    ... However declaring an object volatile tells the compiler that access to ... stored), then add 50 and store the result again. ... Also the C language spec doesn't know about threads, ... copied from memory to register, ...
    (comp.programming.threads)
  • Re: operation on module arguments
    ... But the logic to have this feature in the ... language is pretty reasonable, so I was not too greedy, was I? ... memory for storing a real variable, and let the variable name 'A' refer to that bit of memory." ... It means, for example, that the compiler can't pass A around like a real variable, because when the compiler passes it to a subroutine that might modify it, the compiler also has to pass along the instructions that go with it. ...
    (comp.lang.fortran)
  • Re: How to exit an Ada program with (unix shell) error code?
    ... The compiler could decide that the function result is ... There's no rule that says that the interpretation ... has to mimic the behavior of the C language. ... Irvine Compiler's Ada compiler (the one I masochistically work on ...
    (comp.lang.ada)