Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!rpi!rpi.edu!deven From: deven@pawl.rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga Subject: Re: UNIX vs. Amiga speeds Message-ID: Date: 25 Mar 89 05:52:29 GMT References: <6394@cbmvax.UUCP> Sender: usenet@rpi.edu Reply-To: shadow@pawl.rpi.edu (Deven T. Corzine) Organization: RPI Public Access Workstation Lab, Troy NY Lines: 111 In-reply-to: daveh@cbmvax.UUCP's message of 24 Mar 89 05:36:29 GMT In article <6394@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article , deven@pawl.rpi.edu (Deven Corzine) says: >If you're mainly interested in some form of UNIX call-compatible library, >whether linked or shared, I whole-heartedly agree. There's so much useful >UNIX software out there that's just a little too hard for a busy person such >as myself to port over to the Amiga. Most C compilers have link libraries >with bits and pieces of UNIX function call compatibility, but nothing that'll >handle more than simple ports. Basically, I want the call compatibility; the internal structure is comparatively igsignificant and could be implemented in a number of different ways anyhow. What most defines it is the system calls, libraries and shells/filters/utilities. The system calls provide the base for all the rest. I want to implement the system calls, some of the library calls and a number of filters (including sed) and some utilities and a shell. Then I'll be fairly happy for a while. And yes, the ability to port Unix code fairly directly was a huge point in the whole thing in the first place, most of why I refuse to implement the functionality but typecasting it to Amiga calls, by using an "Execute.device" with an OpenDevice call and IOrequests to handle the exec() call. That's not what I want. I want the functionality AND the semantics of the Unix calls. [I don't like to type UNIX, myself; seems too much like yelling... :-)] There are a few calls where it doesn't make sense to try to implement them correctly; brk() comes to mind. malloc(), realloc() and free() WILL be implemented, however. (And just HOW often is brk() used?) [indirectly through sbrk() and malloc() doesn't count here; malloc() will call AllocMem.) >> The best of both worlds, as it were. I define Unix more by how it can be >> used than by the source code that defines it. >Apparently Apollo allows something like function call compatibility for both >System V and BSD 4.somthing under Aegis these days. No idea how well it >works. UNIX taken from a programming model rather than a user's model is >something I'd certainly welcome on the Amiga, if for no other reason than >the fast porting of UNIX code that would allow. That's the idea... (Plus, I see it as being valuable for new code as well.) >Well, we have yet to have a version of Exec released since there have been >Amigas with MMUs. The MMU could give Amiga systems virtual memory and >some level of protection, without necessarily causing problems on systems >without MMUs. The MMU lets you swap transparently to application software, >without resorting to double pointers (ala Macintosh). It makes things >much more efficient; doing the whole thing in software sounds like big >time trouble. Certainly. I didn't say or imply that Exec couldn't make use of an MMU; merely that it does not, at present. I rather expect that to change, sooner or later. >> If you have the Unix programmer (and user) interface, without paging or >> swapping implemented, and the whole thing implemented on top of Exec as a >> base, I think you'll find comparable speeds. >In my opinion, you're still benchmarking the Amiga OS at that point, just >accessed via a slightly different interface. If you started using messages >through filesystem pipes or whatever, instead of Exec Messages, you'd go >slower. But if you're building UNIX call compatible message passing functions >on top of Exec Messages, than you'll of course be within a function call or >so of the speed of plain Exec. Similarly, if you decide to implement the >System V filesystem and limit transfers to 1K at a time, like AMIX does (or >at least did; maybe 1K isn't a fixed limit), your disk speed may drop; but >if you implement UNIX compatible disk calls on top of FFS, you're obviously >a function call away from AmigaOS speeds. No argument here, except on >whether what you're running can be called UNIX or not. Of COURSE you're still benchmarking the Amiga OS at that point. which is the entire point of the matter; the speeds would have to be comparable. And as I define Unix compatibility more by the system calls available to the programmer than the internal structure used for the Operating System itself, you've still basically got Unix, but with the performance advantages of Exec supporting it. (Along with the REAL low-level stuff done already, like interrupt handling [rather poorly done, I'm afraid -- GURUs are a pretty piss-poor way to handle a program messing up and causing an address error or something. if it tromps all over system structures, then it's a more reasonable action.] and device drivers which work...) And yes, the filesystem pipe() created pipes WILL be internally implemented using Exec messages. How else? Of course it can't be called Unix -- "Unix" is a registered trademark of AT&T and Bell Laboratories. Xenix can't be called Unix, either, but it basically is. [Nevermind that it WILL soon be called Unix...] >> Swapping and paging are by no means *necessary* components of Unix. >> (Fine, maybe they are by some official definition, but not by mine.) >> Unix ran on PDP's in its early days... Was paging actually >> implemented? >No, and it isn't on 80286 machines either. I think PDP's had to dump one >process to disk and get the other, or some such ugliness. I believe >(again, not the UNIX expert here) that the requirement is basically >that all processes start at the same location, by whatever means that >can be achieved. Paging seems to be the best way; even '386 systems use >it instead of segments when running UNIX. If you're not using some form >of memory management, even if you don't call it memory management, I don't >think you're really UNIX. The PDP's probably did something fun like that. And you could do the same on an Amiga, though I wouldn't really want to. Actually, I'm pretty sure the PDP's had memory protection to some extent but NOT support for paging... Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.