Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!utah-cs!utah-gr!stride!l5comp!scotty From: scotty@l5comp.UUCP (Scott Turner) Newsgroups: comp.sys.amiga Subject: Re: BCPL/AmigaDOS Message-ID: <283@l5comp.UUCP> Date: Thu, 4-Jun-87 01:30:48 EDT Article-I.D.: l5comp.283 Posted: Thu Jun 4 01:30:48 1987 Date-Received: Tue, 9-Jun-87 01:56:44 EDT References: <461@inria.UUCP> <1920@cbmvax.cbmvax.cbm.UUCP> <147@l5comp.UUCP> <6083@steinmetz.steinmetz.UUCP> Reply-To: scotty@l5comp.UUCP (Scott Turner) Organization: L5 Computing, Edmonds, WA Lines: 95 Summary: MCC isn't the total villian in this drama folks. In article <6083@steinmetz.steinmetz.UUCP> jesup@kbsvax.steinmetz.UUCP (Randell Jesup) writes: > Then get a real shell :-) [no offense intended] Really, if the >MCC people used the undocumented BCPL interfaces, because they happened to >know exactly what they did, they deserve whatever they get. They have an >unfair advantage over the rest of us to whom those internals are taboo >[even if you know how they work, you can't use them because they aren't > guarenteed to continue to work the way they appear to now. ] I at one time thought as you do, that MCC has an unfair advantage over the rest of us. But then I realized that I was focusing blame in the wrong corner. It isn't MCC's fault that it has an unfair advantage over the rest of us. It isn't MCC's place to document the Amiga to us, that falls to the CATS crew. They have been slow to document pieces of the system that the rest of us could find useful. This gives MCC an advantage over the rest of us. But again, that isn't MCC's fault! Any advantage MCC has, has been given to them by CATS. And this doesn't apply to just the "taboo" BCPL support routines built into the ROM. MCC had the jump on other things that we only later were let in on. Like those nifty packets to make console.handler dance etc. > If you want an EXACT replacement, talk to MCC. If you want something >better, it's coming (and it would be better yet if it wasn't for BCPL). As soon as something better than the MCC shell shows up I'll slap plastic, modem, or whatever real fast. But that's true of ANY of the tools I use. I think it's also important to realize that BCPL the LANGUAGE isn't the real problem here. It's the BCPL environment that someone at MCC has come up with that is the problem. Frankly BCPL could shift it's pointers by 42 and push it's stack sideways so long as I DON'T have to do it too. Both Lattice and Manx generate code and use environments I don't really like. Fine. I don't use either, and neither has had the kind of impact that the BCPL environment has had on my coding. Hence no quaint remarks about Lattice or Manx in my signature. And the slowness of the operation of amigadog can't be laid at the feet of BCPL the language either. Some very poor decisions were made as to how amigadog operates. I doubt these decisions were the result of using BCPL to code it. I see more evidence of "If disks didn't rotate and 68000 programmers had only used push UP stacks" ie "utopian" thinking than any "Well BCPL forced us to.." kind of thinking. (BCPL forced us to read the disk a block at a time, yeah! That's the ticket! :) It seems to me that a few hours with the BCPL source code and most of the problems with disk I/O speed could be cured right up. No need for new handlers, just fix what's there. No need to recode into another language either. > You're right. But the BPTRS hurt you worse inside the DOS than >outside (performance wise). I'm torn over that. Amigadog certainly suffers from BPTR mainge but I don't know who suffers more at times. :-) > It does use up to that amount, from the bottom of the stack up. >Simple calls use only a little, but some can use quite a bit (this is the >upside-down stack referenced off of A1). It doesn't matter if most calls only use a small part of this space. They use it from the bottom, which has the effect of making the fact that they only use a few bytes mute. > NO! You're right that the filing system needs improvement, but there >are MANY other areas that are brain-dead, only available via the undocumented >BCPL calls or just plain missing. The Amiga has been around for nearly TWO YEARS now. That's a long time in this day and age. The Amiga's OS DOES have it's problems. And I'm sure that if given the chance to do it all over again MCC and C-A would do certain things differently. But they DON'T have it to do all over again. The second they released the Amiga's OS it became a standard. Every last bug and blown concept. C-A has kept certain parts of the OS "dark", evidently in the hopes of doing something about them. Almost two years later there has been LITTLE evidence that anything is being done. In fact two new computers are set to be released with the SAME "What ever it is they don't want us to see" code burned into ROM. Granted the WCS would have enabled C-A to fix anything they wanted to easily and thus we should keep out mitts off. But things are different now. And not just now now, but for several months. If this 1.3, that every one keeps dropping hints about, is so close then why are the new machines coming out with 1.2? But it's evident, from what I can gleen from Andy's messages, that 1.3 is going to be a WORKBENCH disk release and not a new ROM release. This dovetails nicely with my comments about things getting cast into ROM and not being easily changed. C-A can change the WB disk all they want without touching the ROM. But if they aren't going to be touching the ROM then what's in the ROM becomes fair game for us to use. Anyone for a bcpl.library? We could cook this up as an interface to the hidden BCPL routines. Then if they change then we would have this library as a buffer between us and the changes. ie it could be re-written rather than our code. This seems like a "safe and sane" answer to the question of getting at the BCPL library in the ROM. Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)