[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: beagle compiler

mdj wrote:

Michael J. Mahon wrote:



I would have thought most of the high level languages were...


I doubt it.  Most were probably written in assembly language, or,
at best, cross-compiled.  (I don't count the IIgs, since that was
a 16-bit system from the point of view of compilers.)



It's a shame that the APW/ORCA environment wasn't used from the get-go
as the foundation layer of the operating system. Much more Apple II
like that what materialised which always felt like they were trying to
out Mac the Mac on a much more limited architecture.


Yes, Apple seems to have taken a cross-development approach just
to improve developer productivity.  Unfortunately, it also tends
to decouple the developers from the system they are supporting,
which can lead to a multitude of problems.

There is much to be said for developing on the native system, since
it makes the developers natural beta testers for everything.  ;-)


In fact, there were *very* few high-level languages for the 8-bit
Apple II that generated object code (as opposed to an interpretive
code), and that approach, if followed in a simplistic way, leads
to a very slow compiler.  (As opposed to the Digitek approach, based
on SDS 940 POPs, which expanded speed critical POPs as macros, making
for a very fast, small compiler.)



True. Kyan Pascal comes to mind as well - I think Willi even has the
source code to the compiler...



The Pascal compiler in Apple Pascal was self hosting, although because the
OS itself was a collection of segment procedures one had to know what
they were doing to replace it.

Of course, since the P-system was portable, it would have made more
sense to build the system on a larger computer than an Apple II :-)


And I supposed that that was how it was made.



Almost certainly, since the source to the P-code engine is written in
UCSD adaptable assembler. Once you have that though, you can quite
conceivably rebuild the entire system on an Apple II.


That may have been the motivation for the relatively robust "unit"
implementation--to allow the system to be natively developed with
tolerable compile times and manageable symbol table sizes.


BTW, if the Pascal system had been profiled, and critical parts macro
expanded, it could have been a *much* faster system.  Then, of course,
the tools to do that could have been made avaialable to users so that
they could speed up their applications considerably, too.



After discussing those concepts with you a while back, I've put such a
project on my back burner, although optimising the OS itself hasn't
really appealed, since the prospect of changing its code size is
worrisome.


It's true that if all you do is expand some ops in-line, then you
increase the net code size.  But in an OS or a compiler, there is
a lot of code that is error handling code that is executed with
a frequency of zero almost all the time and one when an error is
detected.  This code can be made non-resident, freeing up some
space for the macro expansions.


The biggest performance problem with the Pascal system was character
device IO, since such a request went through the p-code based OS to a
pluggable device mapper, and then onto the actual device driver.
Replacing the console driver with a direct-to-80 column card driver in
assembly made massive performance differences.


Yes, I recall that simply in-lining "insymbol" made a huge difference
in compile speed, with an almost negligible cost in space.

When Wirth's (Jensen's) P-code Pascal compiler first became available,
I became interested in porting it to the machines I was supporting
then.  One team wrote a P-code interpreter, and they got the compiler
compiling itself in about an hour.  I wrote a P-code to native code
code generator that did simple peephole optimizations.  My translated
compiler compiled itself in under a minute!  Of course, my version took
about 3x the memory space, or 150KB, but it made the system usable as
a development vehicle.


Of course, the code execution speed was never stellar, but not really
that much slower than compiled Applesoft, with the exception of the IO
issues mentioned above.


Actually, for moat things it was much faster than Applesoft--which
isn't hard since Applesoft sequentially searches the symbol table
for each variable reference!  But it never got within an order of
magnitude of machine code speed.

-michael

New, faster SUDOKU v2.0 solver for Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."