Conference hydra::amiga_v1

    One interesting note, no doubt prompting the existence of GOMF:
    
    By my reading of the disassembled ROM, the DOS library exception
    handler (the one that actually makes the TASK HELD requester) is
    broken in a couple of ways.  One of them makes it likely to get
    a trap as soon as you press one of the requester buttons.  If you
    get past that bug, the other one is almost guaranteed to kill you.
    
    The intent of the code is to loop forever repainting the requester
    if you punch the "RETRY" gadget, or to let the EXEC exception handler
    take care of things if you try cancel.  Under version 1.0, this
    would leave the task in an unrunnable state, with all its resources
    still tied up, but at least no GURU.  Under 1.2, they apparently
    "fixed" something so that the DOS exception code will cause a few
    GURUs of its own on the way to the EXEC exception handler.  Looks
    like when they added 68010 support, they blew an edit (and possibly
    the whole concept of the edit).

    Yeah, that Task Held requestor always made me laugh... your only
    choices are 'die' or 'be killed'.
    
    Has anyone been following the saga of the ARP project?  Charlie
    Heath of MicroSmiths and a number of other Amiga luminaries have
    been busily re-writing most of the BCPL AmigaDOS commands in C or
    assembler.  The resultant equivalent commands are MUCH smaller and
    faster, and in general, more powerful and/or consistant.
    
    One of the benefits of the ARP library will be resource tracking,
    whatever that is.  I plan on uploading the new ARP 1.1 library as
    soon as it's available, in a few more weeks.
    
    One major benefit of the new AmigaDOS commands will be to free up
    lots of valuable disk space on floppy based system disks.  The typical
    ARP command is around 600-700 bytes long.
    
    Watch this space.
    
    Ed.
    

    	I've been using the ARP commands for some time with no
    problems. They definitely occupy less space than the equivalent
    AMIGA DOS commands.
    
    Miguel A.

>    been busily re-writing most of the BCPL AmigaDOS commands in C or


Whats BCPL?

>Whats BCPL?

From what I heard, it should stand for British Crummy Programming Langauge :)

I dont know what it really stands for, but I beleive it is the predecessor
to languages like B, and C

Robb

    Again, from countless hours of looking at disassembled DOS library
    code:
    
    BCPL is a compiler that produces about the worst code I've ever
    seen.  I think any self respecting compiler writer would want to
    form a gang to have the BCPL implementors tar and feathered and
    ejected from this universe.
    
    I would say that if you took all the code on the kickstart ROM that
    was compiled by BCPL and did a trivial code compression pass on
    it, you'd have room for the original DOS library, the ARP library,
    and maybe even a HAM picture of yourself. 
    
    Ok, maybe I exagerate a bit.  But, you can usually get about 50%
    savings in code size by doing simple optimization on the DOS code
    without even touching the original algorithms (which aren't always
    that great either).  Doesn't surprise me at all that ARP can add
    features and save space at the same time.
    

Re: BCPL

BCPL is a typeless programming language for word address machines.  It
was one of the first assembly-language replacement languages devised.

BCPL is an ancestor of both BLISS and C.  BLISS was heavily influenced
by BCPL.  The language B, the typeless version of C first done by
Ritchie, was also based on BCPL.  (There is a joke:  What should
Ritchie call his next programming language?  Once answer is D because
it is the next letter in the alphabet after C.  Another answer is P
because that is the next letter in BCPL.)

Because BCPL was originally designed for word addressed machines,
BCPL programmers are use to adding 1 to an address in order to get
the address of the next word of information.  On a byte addressable
machine this causes problems, because you need to add 4 to the address
to get you to the next (long-) word's worth of data.  The compiler cannot
tell that adding 1 is really an attempt to get to the next word of data
because BCPL is totally typeless:  the compiler can not tell the difference
between data or addresses.  (In BCPL a quantity is only used as an
address if it is on the left hand side of an =, or the "fetch" operator
is applied to it.)  The solution to this problem is that BCPL compiler
multiples the operand of the fetch operator by four to hide the difference
between a byte addressed machine and a word addressed machine.  Thus,
if you read the Amiga programmer's docs you will occasionally see
reference to BPTRs;  a BPTR is a regular address divided by four.  Some
of the AmigaDOS functions return BPTRs as results and take BPTRs as
arguments.  (For example, an AmigaDOS filehandle as returned by the
Open function returns a BPTR to a data structure that the operating
system used to track I/O done to the file.  These filehandles must
be passed as arguments to the Read and Write AmigaDOS functions.)
Most of the time, a programmer doesn't need to look inside of
AmigaDOS's data structures; thus, most of the time you can ignore that
BPTRs exist.

A point needs to be made about AmigaDOS.  The entirety of Amiga system
software has no name.  Sometimes (myself included) refer the the total
of Amiga system software as AmigaDOS or Kickstart.  Technically
however, Kickstart is only the part of the operating system that lives
in ROM on the Amiga 2000/500, and in the write control store of the
Amiga 1000.  AmigaDOS proper is only the upper layer of the I/O and
filesystem of the Amiga, the CLI, and most of the CLI commands.  The
Exec (the heart of the Amiga operating system) is written in assembler.
Intuition (the user interface and windowing system), the Workbench,
and most of the rest of the software is written in C.  Only AmigaDOS
proper is written BCPL.

AmigaDOS proper was a latecomer to complete Amiga operating system.
Amiga Inc. had a contract with an outside company for them to do
the boring stuff (some of the device drivers, the top level of the
I/O system like Open/Read/Write etc.).  This deal fell through at
a very late point in time.  The English company Metacomco was contracted
to port their top level I/O layer from their Tripos operating system
the Amiga.  Thus, AmigaDOS was born.

AmigaDOS (proper) has somewhat of a bad reputation among Amiga programmers.
There are three problems with it:  First, the BCPL code is large and
slow.  Second, if you do really do low level programming, you do have
to be aware of BPTRs and requirements that certain data structures have
to be longword aligned.  Third, their is the BCPL runtime environment.

BCPL is very peculiar.  It is designed to link programs at runtime.  The
BCPL environment in AmigaDOS has a second type of shared runtime library.
Everyone knows that OpenLibrary gets you access to a shared library on
the Amiga.  BCPL programs have their own mechanism for accessing shared
libraries that are not Amiga standard shareable libraries.  Third, there
is the weird BCPL startup requirements.

BCPL programs on the Amiga require that special values be preloaded into
the registers when the program starts.  Furthermore, they require that
special additional information be in the process control block, and that
the I/O streams be slightly munged in order to pass arguments to the
program.  In other words, in order to run a BCPL program, you must be
a CLI.  (Or call the Execute AmigaDOS function which creates a CLI
temporarily to run the program.)  The startup code requirements for
BCPL programs have been purposely not documented by Commodore.  The
reason is that Commodore wants to remove BCPL support from the Amiga,
and doesn't want people relying on the BCPL environment.  This last
causes people who want to write their own CLI a lot of problems.  The
usual answer is to require that custom CLIs run under a real CLI.

Anyway, this offended a few Amiga Developers, and so they started ARP,
the AmigaDOS Replacement Project.  They have been busy rewriting all of
the BCPL commands in c directory so that they can give the results
to Commodore so that Commodore can make good its promise to throw away
the BCPL environment in a future release of the operating system.
An early release of the ARP commands are on a Fish disk, or can be
ordered by sending $5 to the ARP project.

It is interesting that the new fast file system for hard disks is
written in C.  It replaces for hard disks the BCPL filesystem.

There is an amusing follow up to all of this.  The same people responsible
for AmigaDOS proper, held to be the slow and inelegant part of the Amiga's
operating system, are designing all of the new operating system for
Atari's new parallel processor.  There are some that believe this to be
a fine joke on Atari.

Thanks for the detailed explanation, Randy!  Now I know what those
BPTR's things are (and why Conman jokes "no more BPTR's, I promise!"

Looks like ARP is going to fix up AmigaDOS while Atari has fun yet to come...

John

    .7  brings out a question...  I assume 1.3 of AmigaDOS is going
    to use a different, new, whatever disk structure to increase
    performance.  Any guesses as to what we might have to go through
    to migrate our disks to the new format?  Will there be  a new format?
    What gives... etc.... 
    
    john
    

    Latest Usenet rumors from people at Commodore:  v1.3 has several
    minor new features.  The Fast Filing System will be sold as a separate
    product to speed up hard disk performance under AmigaDOS.  FFS is
    not compatible with the current disk format.
    
    The C-A software guys speculated that FFS would be merged into version
    1.4 of the OS, with a compatibility mode or conversion utility to
    read current floppies.  Since they haven't finished 1.3, though,
    take this with a big grain of salt.