Conference hydra::amiga_v1

    
    A nice trick, used by the CSA and Hurricane boards (when equipped
    with 32 bit memory) is to relocate the ROM routines to 32 bit memory
    and access them at 14 MHz.
    
    The CMI Processor Accelerator (that's the 14 MHz 68000/68881 board)
    accesses the ROMs at 14 MHz.  I really don't understand what, if
    anything, this means.  May just be marketing hype.
    
    Ed. 

    re .1
    	When the CMI processor accesses the ROMS at 14 MHz, it is able
    to load the instructions into it's own buffer at twice the speed
    it normally would.  This only speeds up the read part of the operation,
    and although a CMI also speeds up the execution of commands, if
    the OS were written entirely in Assembly,  then, there would be
    far less commands to read (Assembly is optimized), and the same
    amount of work could be accomplished with fewer instructions.  So,
    not only would an Assembly language OS improve standard Amigas,
    but it would also increase the performance of a CMI.  You'll notice
    that in some C language programs, developers actually write sections
    in Assem mnuemonics so that the C compiler won't generate rediculous
    overhead for simple routines.  C is one of the most optimized compilers
    that exists today, but nothing beats the human for finding the
    trickiest, fastest, and shortest ways to write programs.
    	The Arp project, if I'm not mistaken, contains DOS routines
    that are written in assem.  This is a big start, as you'll find
    that their code is much smaller than the original BCPL code, but,
    now, if the ACTUAL OS COMMANDS were in Assem, they would take up
    less space, and execute much faster.  It's a big project, but CBM
    has the manpower, and resources to do it.  Let's have a vote on
    this.
    
     - Chris
    

    
    I'm all for anything that takes up less space... what I'd like to
    see is enough room in the 256K ROMs for some of the nice features
    that Mac owners take for granted, like a standard file requestor
    and more informative dialog boxes.
    
    If you really want to be heard, buy some CBM stock and vote Dale
    Luck (original Amigan extraordinaire) as proxy for your votes. 
    
    Ed.

    I suspect CBM is rewriting sections of the OS in assembler to reduce
    the size and increase the speed, they need to if they want to fit
    new functionality into the 256K ROM.  A 100% assembler implementation 
    isn't absolutely needed, just a rewrite of the critical slow parts.
    
    The intro of that book blames the writing the OS in C for the slowness.
    
    I suspect it isn't OS slowness, but more of a desire to avoid all
    those messy OS calls needed to do things in a well behaved manner.
    The book is full of examples of open library calls that don't specify
    the version or even check it.  They don't ask the input device for
    joystick info, they just read the hardware register.  They have
    hardcoded offsets into data structures instead of using includes
    (that may be because they have their own include files instead
    of the standard ones).  Like I said, a great reference book, but
    NOT if you want to learn the right way to do things in a well behaved
    manner (that won't break with the next release of the OS).
    
    -dave
     

    re: .4  Here, here...I TOTALLY agree...the OS is pretty darn good
    as it is...maybe a bit of tweaking here and there, but overall GREAT.
    the speedup ARP gets you is in the loading from disk, I havent really
    noticed that the smaller exe's run faster...after all, the disk
    is by far the bottle neck...
    
    as for exec, intuition, etc (ie the other parts of the OS, after
    all, CLI is only a part of it)...yes, they could be sped up...but
    optimization is far better than replacement...after all, who want
    to spend HR's, and HR's optimizing something thats not on the critical
    path anyway!....analyze the bottlenecks, then optimize!
    
    And as for sloppy "hacking"...well, I could rant and rave for pages..
    (but won't 8-)  REAL programmers know the benifits from doing things
    the "right way"
    
    scott

    	I'd like to thank everyone for their ideas on this subject.
    It seems that although some portions of the OS aren't exactly running
    at jack-rabbit speed, most are fast enough.  The real advantage
    of total conversion to assembly language apparently lies in the
    reduction of code size.  So, with Assem, we can pack more in the
    the 256K ROMS.  Keep the ideas coming!.
    
     - Chris
    

    
    Actually, not everyone knows this, but most of the folks working
    on v 1.2 were about to be axed.  Of course THEY knew this.  I doubt
    that people do their best work under these conditions.  One of the
    more irritating bugs that came out of this is the famous 'task held'
    requestor, which offers 'cancel' and 'reset' as it's options.  No
    matter which gadget you select, you get clobbered.
    
    Some of the original Amigans still working for CBM have stated that
    most of the graphical routines could be greatly optimized.  This
    will happen under v 1.4, which should appear sometime around the
    turn of the century.
    
    Ed.                                               

The Exec is written in pure assembler.  The rest of the code written
by Amiga Inc (and latter Commodore) was written in C.  Part of new code
is written in assembler (I think the Fast File System is written in
assembler).

Commodore does not use any of the C compilers sold for the Amiga to
write their code.  They use Greenhills C (a true optimizing C compiler)
running on a Sun as a cross-compiler.  The output of an optimizing C
compiler is roughly equivalent to hand coded assembly.  There probably
isn't much to be gained in converting the C code to assembler.

The DOS (the file system layer) provided by Metacomco is written in BCPL.
The BCPL compiler generates poor code even by the standards of unoptimized
microcomputer compilers.  That part of the system software would speed
up and shrink significantly if rewritten into assembler or C.

One major issue is not the code itself, but the algorithms used.  The fast
file system isn't fast because of what it is written in--it's fast because
it uses more intelligent block placement algorithms.  The old file system
is slow on hard disks because it scatters the parts of a file over the
disk, and because it puts a data header at the start of every block that
must be striped before handing the data to a program.  The new file system
allocates things on the disk more intelligently, makes data blocks pure
data so that they can be transferred from the disk directly to user
buffers, and attempts to do 16 bit data transfers when the user buffers
are aligned.  If the old file system was simply recoded into assembly
language, its code would be smaller, but hard disk I/O would still be
slow.

I (and everyone else) would like to see Commodore throw out the BCPL
code.  For them to throw out the C code and rewrite everything into
assembly would be disaster--the enormous investment in time it would
take to do so would be much better spent adding features to the
system.

I basically believe that the book is full of sh*t when it says that
you have to go to the hardware for speed.  A lot of the standard
routines just set up registers for the blitter or what have you,
and perform that proper handshaking to make sure that the hardware
is being used properly in a multitasking environment.  I wonder
which part the book leaves out...

Anyway, the book that prompted this discussion sounds like a fun
read (hey, I ordered it), but I don't want such people messing
with MY system software.

    Having disassembled and commented the 1.2 ROM routines that get
    called by dos.library and what's pointed to by the normal BCPL global
    vector, I can say that if they recoded the BCPL ROM code into decent
    assembler or C, without even changing any algorithms, something
    would be very wrong if they didn't find a 50% reduction in space
    used by those routines.  This is not to say 50% of the total ROM
    gets freed, because thankfully, not that much of the ROM is BCPL
    code.
    
    Believe me:  You can tell by looking at it that it's code produced
    by BCPL.  Furthermore, you can tell by looking at it that the back
    end to that BCPL compiler was either written by someone who never
    did a compiler back end before, was written as a college compiler
    class project (I guess that's the same thing as the first choice),
    or was a very quick and very dirty attempt to just get something
    off the ground as soon as possible.
    
    At the time I did this disassembly/commentary exercise, I came to
    the (somewhat exaggerated) conclusion that recoding the BCPL produced
    ROM code into fairly tight assembly (including cleaning up some
    of the dumber algorithms, perhaps) would free up enough space on
    the ROM to:
    
    Put back whatever was taken out for the 1.3 release
    Insert a parallel copy of the ARP library
    and perhaps: Include a wallet sized IFF HAM picture of the saint
    who did it.
    
    We're talking serious ROM wastage here.  BCPL gives high level
    languages a real bad name (as if they didn't have one already :-)

    
    re:.9  waste of ROM space
    
    Naaa, it's a feature.  They were just reserving that space for 
    "future optimization".  If it looked unused, then somebody might
    be temped to use it.  Besides if they got it right the first time,
    how would they speed up the next release to compensate for the 
    added overhead of more features :-)
    
    -dave

    And as for ROM space...since all the ROM really needs to do is "boot"
    the darn thing, what's the difference....no seriously...if a few
    K of extra stuff has to come off the disk, and can be easily upgraded,
    who cares...at least untill it becomes a significat fraction of
    the total RAM...
    
    
    scott.
    

RE: < Note 1708.9 by STAR::BANKS "In Search of Mediocrity" >
              -< Just wander up ROM until you can smell it: BCPL >-

>    Having disassembled and commented the 1.2 ROM routines that get
>    called by dos.library and what's pointed to by the normal BCPL global
>    vector, I can say that if they recoded the BCPL ROM code into decent
>    assembler or C, without even changing any algorithms, something
>    would be very wrong if they didn't find a 50% reduction in space
>    used by those routines.  This is not to say 50% of the total ROM
>    gets freed, because thankfully, not that much of the ROM is BCPL
>    code.

       I don't think that rewriting BCPL code into C is gonna buy you
    what you are looking for.  C was originally derived from BCPL, I
    think what you could wish for here, is a better BCPL compiler.
    
>    Believe me:  You can tell by looking at it that it's code produced
>    by BCPL.  Furthermore, you can tell by looking at it that the back
>    end to that BCPL compiler was either written by someone who never
>    did a compiler back end before, was written as a college compiler
>    class project (I guess that's the same thing as the first choice),
>    or was a very quick and very dirty attempt to just get something
>    off the ground as soon as possible.

        I believe metacomco wrote their own bcpl compiler, they sell a
     version of it for the atari st.  I am sure they have a version for
     the amiga available.
    
>    We're talking serious ROM wastage here.  BCPL gives high level
>    languages a real bad name (as if they didn't have one already :-)

        Again, I feel that the problem is in the compiler, and not in
     the language.
     
     any dissagreements?
     
     Bill Powers
     

    Hmmm...  Metacomco ported Tripos to become AmigaDOS using their
    own BCPL compiler.  If there is a better BCPL compiler out there
    then one could reasonably expect that Commodore would already have
    used it to recompile existing code.
    
    In this case, I suspect that the blaming the language or the compiler
    is a distinction without a difference.  On the other hand, Green
    Hills C and other similar cross-development environments are well
    known to produce tight code.  So the result would justify the
    translation.
    
    I'm going to sidestep the BCPL vs. C question here, and just say
    that both are mature languages.  Note that for compatibility reasons
    AmigaDOS in any language is probably going to have those cockamamie
    BPTRs forever.
    
    Wes Plouff

Re:.12

Your major point is well taken: A better BCPL compiler (and it would be
hard to find a worse one) would greatly improve the code.  However,
BCPL is a dying (if not dead) language.  That better compiler seems
not to exist.

C, although a second generation descendant of BCPL, is quite a different
language.  BCPL is only really happy on a word addressed machine; C is
designed for a byte addressed machine.  BCPL is inefficient on a byte
addressed machine.  BCPL is typeless--its only data type is the word.
Addresses are assumed to be word addresses, and adding one to an
address must give you the next word.  The way that Metacomco made this
work on a 68000 was that every time a pointer is dereferenced, it is
first shifted by two.  Thus, Amiga programmers dealing with the file
system have to deal with BPTRs and BSTRINGs and longword aligned
data structures.  The DOS itself spends a lot of time shifting pointers
by two.  All of that could be eliminated if the BCPL code was rewritten
in C.  (New DOS entry points would be created that took real pointers,
and the old entry points that took BPTRs would just shift their
arguments and call the new entry points.  Compatibly, yet new code
could avoid the inefficiencies by using the new entry points.)

There is a runtime system issue as well.  The BCPL code in the Amiga
uses its own, undocumented, shareable library that is completely
unlike the standard Amiga libraries.  That code could be eliminated
if the BCPL code was rewritten.

The BCPL code also uses an undocumented startup sequence.  This makes
it hard for people who write command shells and the like.

The world would just be a better place if BCPL disappeared :-).

    Yes, I was making the mistake of equating BCPL with the sh*tty
    implementation used on the Amiga, and I didn't really mean to sound
    like I was badmouthing BCPL, The Language.
    
    Rather, I was just badmouthing the particular implementation used
    on the Amiga.  Believe me:  The code that pig produces is worse
    than any commercial C compiler for the Amiga, and probably worse
    than the public domain ones.  As a matter of fact, I'd be surprised
    if a student C compiler project that produced code that bad wouldn't
    be justification for a failing grade.  (I know compiler writing
    ain't that easy, but there are some mistakes in the produced code
    that tells me the back end writer didn't even accurately describe
    the 68000's instruction set to the compiler.)
    
    If I sound a little militant about it, it's because I am.  Sure, we
    could argue that RAM is cheap, and so what if some bumbling code makes
    me have to slap an additional 64-128K on the machine to make up the
    difference.  Then again, RAM isn't that cheap anymore and I paid good
    money for the code (as I expect it to be rolled into the purchase price
    of the machine). If the base software for the machine is incompetent,
    it causes the whole package (hardware and software) to be much less
    attractive, especially when that base software is part of the OS (which
    the DOS mostly is).  Third party software may be nice, but all the
    packages you'll buy for the machine will probably be written for the
    vendor supplied OS.  If the vendor supplied OS stinks, then the whole
    fish is liable to stink. 
    
    Now, that having been said, I understand that the Metacomco
    contributions to the ROM were a last minute hack to get the machine
    shoved out the door ASAP (as is common practice in our industry).
    Then again, that was version 1.0.  It would seem that by the time
    we get to version 1.2. they should have either recoded the DOS to
    a real language, or at least cleaned up the BCPL back end.
    
    Well, if not by 1.2, maybe by 1.3.  But wait!  1.3 comes out, not
    with the code cleaned up, but with other parts of the ROM kicked
    out into RAM to make way for the new features.  I wouldn't so much
    mind the additional RAM requirements imposed by this if there wasn't
    so much wasted ROM to be reclaimed.  And reclaiming all those cycles
    wasted with (load memory, shift 2, use as base for a fetch) repeated
    three times in a row (all referencing the same address) wouldn't
    be so shabby, either.
    
    This would be very sad if I let myself forget that we (DEC) do this
    sort of thing all the time, so I guess my flaming should just be
    left as random flaming.