fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (08/03/88)
A friend and I were discussing the AmigaDOS Replacement Project (ARP).
He wondered how the ARP commands were kept so small. Many of them are less
than 1K in executable form. The only explanation I could give was that the
commands called routines in a runtime library. Is that correct? Does ARP
require a runtime library or do you just neet the library at compile time?
Is there anything else that would explain how the programs are kept so
small? Any information would be appreciated.
--Fabbian Dufoe
350 Ling-A-Mor Terrace South
St. Petersburg, Florida 33705
813-823-2350
UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3
...uunet!pdn!jc3b21!fgd3kim@amdahl.uts.amdahl.com (Kim DeVaughn) (08/05/88)
In article <441@jc3b21.UUCP>, fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > > He wondered how the ARP commands were kept so small. Many of them are less > than 1K in executable form. The only explanation I could give was that the > commands called routines in a runtime library. Is that correct? Does ARP > require a runtime library or do you just neet the library at compile time? > > Is there anything else that would explain how the programs are kept so > small? Any information would be appreciated. Two reasons for their small size: You got the 1st one ... ARP does indeed use a runtime lib (arp.library), which is 14396 bytes for the current (v1.1) release. Second, all the individual commands (as well as the aforementioned library) are coded in nice tight assembly language. You can use the arp.library function()'s in your code to do a variety of useful things. To do so, you also need to link in the compile time lib's (arp.lib and/or a.lib) with your code, and any required lib's from your compiler vendor. That cover it? /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (08/05/88)
In article <a1pLGe6ELR1010JQCv2@amdahl.uts.amdahl.com>, kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes: > Second, all the individual commands (as well as the aforementioned library) > are coded in nice tight assembly language. I thought the idea behind ARP was to rewrite AmigaDOS in C. Are you sure everything is done in assembler? Was that a departure from the original intention or did I just misunderstand? --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3 ...uunet!pdn!jc3b21!fgd3
lbruck@eneevax.UUCP (Lewis S.Bruck) (08/07/88)
In article <444@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > I thought the idea behind ARP was to rewrite AmigaDOS in C. Are you >sure everything is done in assembler? Was that a departure from the >original intention or did I just misunderstand? I think the intention was to get the commands away from BCPL (the native language of TRIPOS, on which AmigaDOS was based). This allowed better integration into the C-based environment of the Amiga (in terms of data structures and data types (bye bye BPTRs). Another goal was standardizing the syntax of the commands and giving a more useful wildcard implementation. Lewis Bruck lbruck@eneevax.umd.edu Official? Who said anything ahbout official...
kim@amdahl.uts.amdahl.com (Kim DeVaughn) (08/07/88)
In article <1702@eneevax.UUCP>, lbruck@eneevax.UUCP (Lewis S.Bruck) writes: > In article <444@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > > I thought the idea behind ARP was to rewrite AmigaDOS in C. Are you > >sure everything is done in assembler? Was that a departure from the > >original intention or did I just misunderstand? > > I think the intention was to get the commands away from BCPL (the native > language of TRIPOS, on which AmigaDOS was based). This allowed better integration > into the C-based environment of the Amiga (in terms of data structures and > data types (bye bye BPTRs). Another goal was standardizing the syntax of > the commands and giving a more useful wildcard implementation. Exactly right, Lewis. And while I can't say that positively *everything* is in assembler, I believe that that is the case. Certainly the majority of the ARP distribution is (user commands, and arp.library, that is). /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill Kinnersley) (08/08/88)
[In "Re: ARP commands--How do you make them so small?", Kim DeVaughn said:] > > In article <1702@eneevax.UUCP>, lbruck@eneevax.UUCP (Lewis S.Bruck) writes: > > In article <444@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > > > I thought the idea behind ARP was to rewrite AmigaDOS in C. Are you > > >sure everything is done in assembler? Was that a departure from the > > >original intention or did I just misunderstand? > > > > I think the intention was to get the commands away from BCPL (the native > > language of TRIPOS, on which AmigaDOS was based). This allowed better > integration > > into the C-based environment of the Amiga (in terms of data structures and > > data types (bye bye BPTRs). Another goal was standardizing the syntax of > > the commands and giving a more useful wildcard implementation. > > Exactly right, Lewis. And while I can't say that positively *everything* > is in assembler, I believe that that is the case. Certainly the majority > of the ARP distribution is (user commands, and arp.library, that is). > BCPL commands have a considerable size advantage over C simply because they access their own run-time library in Kickstart. This library is not directly available to C programs. Some of the calls in that library have been brought out and made available to the C world as the AmigaDOS library. Some of them duplicate what you would find in c.lib or lc.lib. A few of them, however, are not otherwise available. So there's more than just a size advantage. BCPL programs can do things that C programs cannot! Instead of going the ARP route and writing everything in assembler, an easier approach is to find a way to interface C to this library. An example of how to do this is shown below. To avoid flames I've shortened this to the bare minimum. If anyone is interested, I can mail them further details on the contents of the library, and replacement programs written in C for: newcli.c endcli.c run.c Bill Kinnersley Physics Department BITNET: iphwk@mtsunix1 Montana State University INTERNET: iphwk%mtsunix1.bitnet@cunyvm.cuny.edu Bozeman, MT 59717 CSNET: iphwk%mtsunix1.bitnet@relay.cs.net (406)994-3614 UUCP: ...psuvax1!mtsunix1.bitnet!iphwk "This message was packed as full as practicable by modern electronic equipment. Some settling of contents may have occurred during transmission." ------------------ /* hello.c - An Example Of Calling The BCPL Library From C /* /* Compile and link with Manx 3.4: /* cc hello /* ln hello.o bcpllib.o -lc /* /* Author: Bill Kinnersley /* Date: Mar 12, 1988 /* Mail: Physics Dept. /* Montana State University /* Bozeman, MT 59717 /* BITNET: iphwk@mtsunix1 /* INTERNET: iphwk%mtsunix1.bitnet@cunyvm.cuny.edu /* UUCP: psuvax1!mtsunix1.bitnet!iphwk */ #include <stdio.h> #include <exec/memory.h> #include <libraries/dosextens.h> #include "BCPL.h" void *AllocMem(); extern long *a; main() { long proc, root, n, num; struct Process *mytask; char *s, *t, *buf; BPTR bs, bt; BCPLInit(); proc = BCPL(FINDTASK); printf("My CLI Process is at %lx\n",proc); root = BCPL(FINDROOT); printf("The root is at %lx\n", root); s = "Here's a tab:%T5, a signed:%N, and an unsigned:%U8\n"; bs = MakeBSTR(s); BCPL(WRITEF, bs, -1L, -1L); BCPL(NEWLINE); FreeBSTR(bs); BCPLQuit(); } ------------------- /* bcpllib.c - An Interface Permitting Calls To The BCPL Library From C /* /* Compile using Manx 3.4a /* cc bcpllib.c /* /* Author: Bill Kinnersley /* Date: Mar 12, 1988 /* Mail: Physics Dept. /* Montana State University /* Bozeman, MT 59717 /* BITNET: iphwk@mtsunix1 /* INTERNET: iphwk%mtsunix1.bitnet@cunyvm.cuny.edu /* UUCP: psuvax1!mtsunix1.bitnet!iphwk */ #include <libraries/dosextens.h> #include <functions.h> #include <exec/memory.h> long a0[3], /* for a copy of the BCPL registers */ *a1, *a; BCPLInit() { struct DosLibrary *doslib; struct Task *mytask; long *splower; doslib = (struct DosLibrary *)OpenLibrary("dos.library",0L); a0[0] = doslib->dl_A2; a0[1] = doslib->dl_A5; a0[2] = doslib->dl_A6; a1 = (long *)AllocMem(2000L, MEMF_CLEAR); a = &a1[3]; /* a points to memory allocated for my BCPL stack. (Yes, I know, I could have put this on the process stack) */ } BCPLQuit() { FreeMem(a1, 2000L); } long BCPL(n) long n; { #asm movem.l d4-d7/a2-a5,-(a7) movea.l a7,a0 adda.l #40,a0 movem.l (a0),d0-d4 adda.l #4,a0 movea.l _a,a1 moveq #9,d5 l1: move.l (a0)+,(a1)+ dbf d5,l1 movea.l _a1,a1 lea _a0,a0 movem.l (a0)+,a2/a5-a6 suba.l a0,a0 move.l 0(a2,d0.l),a4 moveq #$c,d0 jsr (a5) move.l d1,d0 movem.l (a7)+,d4-d7/a2-a5 #endasm } BPTR MakeBSTR(s) char *s; { long len; char *bs; len = (long)strlen(s); bs = (char *)AllocMem(len+2L,MEMF_CLEAR); if (!bs) {printf("Can't allocate\n"); exit(0);} bs[0] = len; strcpy(&bs[1], s); return ((long)bs)>>2; } FreeBSTR(bs) long bs; { char *s; s = (char *)BADDR(bs); FreeMem(s,(long)(*s)+2L); } ---------------- /* bcpl.h - Header File To Allow Calls To The BCPL Library /* From C Language Programs /* Author: Bill Kinnersley /* Date: Mar 12, 1988 /* Mail:Physics Dept. /* Montana State University /* Bozeman, MT 59717 /* BITNET: iphwk@mtsunix1 /* INTERNET: iphwk%mtsunix1.bitnet@cunyvm.cuny.edu /* UUCP: psuvax1!mtsunix1.bitnet!iphwk */ long BCPLInit(), BCPL(), MakeBSTR(); #define bptr(p) (((long)p) >>2) #define SYSREQUEST -0x84L #define TOCSTR -0x80L #define TOBSTR -0x7cL #define EXECUTEC -0x6cL #define ISINTERACT -0x68L #define DATESTAMPC -0x64L #define SETPROTECT -0x60L #define SETCOMMENT -0x5cL #define DEVICEPROCC -0x58L #define QUEUEPKT -0x54L #define CLEARMEM -0x50L #define LOADSEG -0x4cL #define CREATEPROCC -0x48L #define IOERR -0x44L #define CURRENTDIR -0x40L #define CREATEDIRC -0x3cL #define INFO -0x38L #define EXNEXT -0x34L #define EXAMINE -0x30L #define LOCKC -0x2cL #define RENAMEC -0x28L #define DELETEFILE -0x24L #define SEEK -0x20L #define WRITE -0x18L #define READ -0xcL #define STRNCPY -0x8L #define OPEN -0x4L #define START 0x4L #define EXIT 0x8L #define MULTIPLY 0xcL #define DIVIDE 0x10L #define MOD 0x14L #define SETIO 0x18L #define PACKLW 0x20L #define UNPACKLW 0x24L #define SETRES2 0x28L #define MAKEGV 0x34L #define FINDTASK 0x38L #define GETBYTE 0x3cL #define PUTBYTE 0x40L #define LEVEL 0x44L #define LONGJUMP1 0x48L #define ALLOCMEM 0x4cL #define LONGJUMP2 0x50L #define DOIO 0x54L #define SENDIO 0x58L #define CREATECO 0x5cL #define DELETECO 0x60L #define CALLCO 0x64L #define COWAIT 0x68L #define RESUMECO 0x6cL #define INSTALLSEG 0x70L #define GETVEC1 0x74L #define FREEVEC 0x78L #define OPENDEV 0x7cL #define CLOSEDEV 0x80L #define CREATEPROCB 0x84L #define REMPROCESS 0x88L #define PARENTDIR 0x8cL #define SETSIGS 0x90L #define CLEARSIGS 0x94L #define DOSALERT 0x98L #define FINDROOT 0x9cL #define READINC 0xa0L #define TASKWAIT1 0xa4L /* same as 190 */ #define PUTPKT 0xa8L #define WRITEOUTC 0xacL #define PACKSTRING 0xb0L #define UNPACKSTRING 0xb4L #define HOLDTASK 0xb8L #define DELAY 0xbcL #define SENDPKT 0xc0L #define RETURNPKT 0xc4L #define OPENWINDOW 0xc8L #define SETCURDIR 0xccL #define BUILDSYSREQ 0xd0L #define WRITET 0xd4L #define RDCH 0xd8L #define UNRDCH 0xdcL #define WRCH 0xe0L #define READINB 0xe4L #define WRITEOUTB 0xe8L #define FINDINPUT 0xecL #define FINDOUTPUT 0xf0L #define SELECTINPUT 0xf4L #define SELECTOUTPUT 0xf8L #define ENDREAD 0xfcL #define ENDWRITE 0x100L #define INPUT 0x104L #define OUTPUT 0x108L #define READN 0x10cL #define NEWLINE 0x110L #define WRITEI 0x114L #define WRITEN 0x118L #define WRITEHEX 0x11cL #define WRITEOCT 0x120L #define WRITES 0x124L #define WRITEF 0x128L #define TOUPPER 0x12cL #define CHARCMP 0x130L #define STRCMP 0x134L #define RDARGS 0x138L #define RDLINE 0x13cL #define PARSESTRING 0x140L #define LOAD 0x144L #define UNLOAD 0x148L #define TIDYUP 0x150L #define ADDDEVICE 0x154L #define DATESTAMPB 0x158L #define WAITFORCHAR 0x15cL #define EXECLIB 0x160L #define FINDSEGARRAY 0x164L #define DELETEOBJ 0x168L #define RENAMEB 0x16cL #define CLOSE 0x174L #define GETWORD 0x178L #define PUTWORD 0x17cL #define TASKWAIT2 0x190L /* same as a4 */ #define EXECUTEB 0x194L #define DEVICEPROCB 0x198L #define LIBCALL 0x19cL #define WRITEERR 0x1a0L #define FINDCONHAND 0x1a4L #define FINDFILEHAND 0x1a8L #define EXTDEVNAME 0x1acL #define LOCKB1 0x1b0L /* same as 1ec */ #define UNLOCK 0x1b4L #define GETLONG 0x1b8L #define PUTLONG 0x1bcL #define OPENFILE 0x1c0L #define DUPLOCK 0x1c4L #define MAKESYSREQ 0x1c8L #define STRCPY 0x1ccL #define RUNLOADED 0x1e4L #define LOCKB2 0x1ecL /* same as 1b0 */ #define FINDDEVINFO 0x1f0L #define CREATEDIRB 0x1f4L #define CMPTIME 0x1f8L #define TIMERIO 0x1fcL #define SETTIME 0x200L #define FINDCLI 0x218L ----------------
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (08/10/88)
[ Did Britain really pull the plug on Greenwich Observatory's atomic clocks? ]
Your dilligent searching out and mapping of AmigaDOS and its BCPL
realm is to be commended. However, CATS types have said in the past that
they are opposed to documenting the BCPL entry poiints, since that will make
it all the more difficult for them to go in and re-write DOS in C and
assembly.
Therefore, I would suspect that using the information to any great
extent beyond intellectual curiosity is not a good idea. It's not
supported, and Commodore reserves the right to break anything that's not
supported.
Caveat programmer, I guess.
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU
\_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac
O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack")
"Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctorncreed@ndsuvax.UUCP (Walter Reed) (08/11/88)
In article <6788@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > Your dilligent searching out and mapping of AmigaDOS and its BCPL >realm is to be commended. However, CATS types have said in the past that >they are opposed to documenting the BCPL entry poiints, since that will make >it all the more difficult for them to go in and re-write DOS in C and >assembly. How about this... Can someone from CBM say if programs that use this will break under 1.4? Simple yes or no would suffice and it would give us some kind of lifetime estimate for programs that do access these little tricks. If it will work under 1.4, then I can use these nifty features knowing that it will at least work for a year or so. from little things i've heard on the net it seems that CBM at least knows what will go into 1.4. -- ------ Walter Reed ------ + uunet!ndsuvax!ncreed or ncreed@ndsuvax.BITNET "There's no point in being + or ncreed@plains.NoDak.edu grown up if you can't be + Phone: (701) 235-0774 childish sometimes!" Dr. Who + USnAIL: 1430 12 Ave N. Fargo, ND 58102
andy@cbmvax.UUCP (Andy Finkel) (08/23/88)
In article <3633@louie.udel.EDU> iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill Kinnersley) writes: > Instead of going the ARP route and writing everything in >assembler, an easier approach is to find a way to interface C to this >library. An example of how to do this is shown below. >Bill Kinnersley I've thought long and hard for a suitable response. On one hand, I applaud the intellectual search for knowledge. On the other hand, I hope this doesn't show up in a commercial product. (I hate to have my options limited.) Anyway, I think Roger Zelazny, in his excellent book _Lord of Light_ tells it best... ------------------------ "It begins with a doorway. There is a huge, burnished metal door, erected by the First, that is heavy as sin, three times the height of a man and half that distance in width. It is a full cubit thick and bears a head-sized ring of brass, a complicated pressure-plate lock and an inscription that reads, roughly, "Go away. This is not a place to be. If you do try to enter here, you will fail and also be cursed. If somehow you suceed, then do not complain that you entered unwarned, nor bother us with your deathbed prayers." Signed, "The Gods." [...] It is told that Pannalal the Sage, having sharpened his mind with meditation and diverse asceticisms, had divined the operation of the lock and entered Hellwell, spending a day and a night beneath the mountain. He was thereafter known as Pannalal the Mad." ------------------------- I think that sums it up just about perfectly :-) (sorry Bill) Right now, the Universe of Programs that we break by playing with the (undocumented on purpose) BCPL global vector and associated libraries is small, and known. We could handle the screams of outrage if we changed things (I think). If the Universe of Programs that count on this stuff gets large, it becomes harder. (Its our plan to provide C library interfaces to the useful routines at some point in the future.) Think of this as fair warning. I like the spirit of experimentation... as long as the fruits of discovery don't automatically become something to be counted on. (_Lord of Light_ is a must book, btw. I think its one of Zelazny's best; and, like all true classics, has a bearing on many situations you encounter in life; The passage quoted above is a perfect example...it fits the situation *so* well. The book review is concluded; we now return you to the regular discussion of proper pronunciation of punctuation found in comp.sys.amiga. ) -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "If we can't fix it, it ain't broke." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill Kinnersley) (08/25/88)
[In "Re: ARP commands--How do you make them so small?", Andy Finkel said:] > > In article <3633@louie.udel.EDU> iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill > Kinnersley) writes: > > Instead of going the ARP route and writing everything in > >assembler, an easier approach is to find a way to interface C to this > >library. An example of how to do this is shown below. > > >Bill Kinnersley > > I've thought long and hard for a suitable response. On one hand, > I applaud the intellectual search for knowledge. On the other hand, > I hope this doesn't show up in a commercial product. (I hate > to have my options limited.) > > > Anyway, I think Roger Zelazny, in his excellent book _Lord of Light_ > tells it best... > > "It begins with a doorway. There is a huge, burnished > metal door, erected by the First, that is heavy as sin, > three times the height of a man and half that distance > in width. It is a full cubit thick and bears a head-sized > ring of brass, a complicated pressure-plate lock and an > inscription that reads, roughly, "Go away. This is not a > place to be. If you do try to enter here, you will fail > and also be cursed. If somehow you suceed, then do not > complain that you entered unwarned, nor bother us > with your deathbed prayers." Signed, "The Gods." > > It is told that Pannalal the Sage, having sharpened > his mind with meditation and diverse asceticisms, had > divined the operation of the lock and entered Hellwell, > spending a day and a night beneath the mountain. He > was thereafter known as Pannalal the Mad." > > > I think that sums it up just about perfectly :-) (sorry Bill) > > Right now, the Universe of Programs that we break by playing > with the (undocumented on purpose) BCPL global vector and > associated libraries is small, and known. We could handle the ^^^^^^^^^^^^^^^^ But how do you *know* it is small and known? When programs start doing magic things, I start to wonder.. > screams of outrage if we changed things (I think). If the Universe > of Programs that count on this stuff gets large, it becomes > harder. > (Its our plan to provide C library interfaces to the useful routines at some > point in the future.) Perhaps this could become part of ARP. > Think of this as fair warning. I like the spirit of experimentation... > as long as the fruits of discovery don't automatically become something > to be counted on. > > -- > andy finkel {uunet|rutgers|amiga}!cbmvax!andy > Commodore-Amiga, Inc. > Andy, we all know and appreciate how much you've helped already to make AmigaDOS more accessible to C, especially with the AmigaDOS devices. I had gotten the impression that this project was largely on the back burner now... that we had reached a peaceful accommodation with BCPL and that things were likely to remain the way they are for some time to come. Excuse me if I was wrong. At any rate, it's clear that your response can only be properly answered by another quote from _Lord_Of_Light_ :-) Enlightened One, I have listened to your teachings, and I have listened well. Much have I thought upon your words. They have filled me with a kind of joy. They have shown me another way to salvation, a way which I feel to be superior to the one I previously followed. Your way of renunciation is a strict one, which I feel to be good. It suits my needs. Therefore I request permission to be taken into your community of seekers, and to follow your path. -- Bill Kinnersley Physics Department BITNET: iphwk@mtsunix1 Montana State University INTERNET: iphwk%mtsunix1.bitnet@cunyvm.cuny.edu Bozeman, MT 59717 CSNET: iphwk%mtsunix1.bitnet@relay.cs.net (406)994-3614 UUCP: ...ucbvax!mtsunix1.bitnet!iphwk "This message was packed as full as practicable by modern electronic equipment. Some settling of contents may have occurred during transmission."