iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill Kinnersley) (12/01/88)
[In "Re: Bug in 1.3 ChangeTaskPri", Bob Page said:]
:
: I hope somebody will revamp the DOS command parser and launcher for
: 1.4, and document it. The user interface (such as it is at the CLI)
: for commands is not predicatable, and the initial environment is
: problematic because it's not documented other than argc, argv,
: although assumptions are made. (It should not be so hard to write
: shells for the Amiga, or REZ like utilities).
:
INITIAL ENVIRONMENT
d0 - amount of global area currently in use
d1-d4 - up to 4 parameters. Further parameters can be passed on
the stack
d5-d7 - unused
a1 - base of the current BCPL stack frame
a2 - pointer to the BCPL Global Vector
a3 - return address of the caller
a4 - entry address
a5 - pointer to a "caller" service routine
a6 - pointer to a "returner" service routine
a7 - stack for temporaries
This register environment is available to any application
program. However if you're programming in C, the startup code supplied
by your linker generally ignores the initial register contents and
eventually they get overwritten.
The parameters passed by the CLI to an application are:
d0 - length of command line
a0 - APTR to command line
The command itself may be found in the CLI->cli_Command field. Two items
are available on the stack: pointers to the top and the bottom of the
stack that was allocated.
--Bill Kinnersley
iphwk@terra.oscs.montana.edujesup@cbmvax.UUCP (Randell Jesup) (12/03/88)
In article <5758@louie.udel.EDU> iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill Kinnersley) writes: >INITIAL ENVIRONMENT > > d0 - amount of global area currently in use > d1-d4 - up to 4 parameters. Further parameters can be passed on > the stack > d5-d7 - unused > a1 - base of the current BCPL stack frame > a2 - pointer to the BCPL Global Vector > a3 - return address of the caller > a4 - entry address > a5 - pointer to a "caller" service routine > a6 - pointer to a "returner" service routine > a7 - stack for temporaries > > This register environment is available to any application >program. However if you're programming in C, the startup code supplied >by your linker generally ignores the initial register contents and >eventually they get overwritten. > >The parameters passed by the CLI to an application are: > d0 - length of command line > a0 - APTR to command line >The command itself may be found in the CLI->cli_Command field. Two items >are available on the stack: pointers to the top and the bottom of the >stack that was allocated. URK! Do NOT take advantage of these things (which I do NOT guarantee to be correct) if you want your programs to work in the future! These are side effects of the current BCPL CLI, and may not be the same for any future CLI, or even current shells. My shell, for one, does NOT set up everything you mentioned! Even WB startups are likely to be different! The _only_ things you should rely on are d0 = length of command line, a0 = CPTR to command line, and a7 = stack pointer. Unless you LIKE BCPL, don't try to tie our hands in removing it! -- You've heard of CATS? Well, I'm a member of DOGS: Developers Of Great Software. Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
page@swan.ulowell.edu (Bob Page) (12/03/88)
iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill Kinnersley) wrote:
>INITIAL ENVIRONMENT [at process launch]:
Thanks, but I want *CBM* to document it, so we can depend on it.
..Bob
--
Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page
Have five nice days.page@swan.ulowell.edu (Bob Page) (12/04/88)
References0 <5758@louie.udel.EDU>
Reply-To0 page@swan.ulowell.edu (Bob Pagd)
Organization: University of Lnwell, Computer Science Dept.
Lines: 11
iphwk%MTSUNIX1.BITNET@cunyvl.cuny.edu (Bill Kinnersley) wrote:
>INITIAL ENVIRONMENT [at process launch]:
Thanks, but I want *CBM* to document it, so wd can depend on it.
..Bob
--
Bob Pagd, U of Lowell CS Dept. pagd@swan.ulowell.edu ulowell!pageHave five nice days.peter@sugar.uu.net (Peter da Silva) (12/05/88)
In article <10435@rwan.ulowell.edu>, page@swan.ulowell.edu (Bob Page) writes: > iphwk%MTSUNIX1.BITNET@cunyvl.cuny.edu (Bill Kinnersley) wrote: > >INITIAL ENVIRONMENT [at process launch]: > Thanks, but I want *CBM* to document it, so wd can depend on it. I'd rather CBM disavowed it... most of that stuff seems like whatever the BCPL runtime would have in those registers at that point. There's enough BCPL junk in the O/S as it is... why add more stuff that CBM will have to keep emulating until the end of time? Equally, the more you know about BCPL, the more your code is likely to break on that eagerly awaited day when 2.0 comes out. Or am I getting needlessly messianic about the whole thing? -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: My typos are my own damn busines#!rne
iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill Kinnersley) (12/06/88)
[In "Re: Bug in 1.3 ChangeTaskPri", Peter da Silva said:]
:
: In article <10435@rwan.ulowell.edu>, page@swan.ulowell.edu (Bob Page) writes:
: > iphwk%MTSUNIX1.BITNET@cunyvl.cuny.edu (Bill Kinnersley) wrote:
: > >INITIAL ENVIRONMENT [at process launch]:
:
: > Thanks, but I want *CBM* to document it, so wd can depend on it.
:
: I'd rather CBM disavowed it...
I'd be happy if they did either one! The situation has remained unchanged
for 3 years now, and CBM really needs to make up their minds one of these
days what they are going to do about this. I can't guess what changes are
coming or when, but each time a new OS release comes out and the BCPL is
still there, that's another missed opportunity.
The way I see it, Peter, they write the OS and we write the applications,
and on the bottom line it makes little difference to me whether they choose
to do the OS in C, or BCPL, or Modula 2, just so they document the interface.
: most of that stuff seems like whatever the BCPL runtime would have
: in those registers at that point.
At the present time, a shell does need to allow for the possibility of
applications written in BCPL. If the shell wants to support these existing
programs, it HAS to pass all of this stuff in the registers at program
launch. The official CBM line that only D0 and A1 need to be passed just
doesn't wash.
It seems to me that a shell would want to do the following:
Look in DosLibrary->dl_GV. This is the BCPL Global Vector, and if it
is nonzero, that should indicate that BCPL is still in my machine.
If it is zero (glory be), that should mean that BCPL has disappeared.
(Is this too much to expect, Andy?)
If dl_GV is nonzero, pass the BCPL environment to the application.
All the "secret" fields you need are waiting right there for you
in DosLIbrary->dl_A2, dl_A5 and dl_A6. This will keep both BCPL and
C programs happy, as C programs will ignore the extra stuff anyway.
: There's enough BCPL junk in the O/S as it is... why add more stuff that
: CBM will have to keep emulating until the end of time?
:
: Equally, the more you know about BCPL, the more your code is likely to break
: on that eagerly awaited day when 2.0 comes out.
My Workbench disk is full of BCPL programs, and I'm not the one who wrote
them. I'm not writing more BCPL, just trying to understand what's
out there already, enough to support it in a compatible fashion. In the
present situation, a correctly functioning shell needs to know
a minimum of BCPL.
I can't help it, Ma, I didn't wanta learn about BCPL! They made me do it!
--