NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/arch/11964

Text File | 1992-12-27 | 5.2 KB | 104 lines

Newsgroups: comp.arch
Path: sparky!uunet!rde!ksmith!keith
From: [e-mail] (Keith Smith)
Subject: Re: IBM AS/400 is the world's slowest computer
Organization: Keith's Computer, Hope Mills, NC
Date: Mon, 28 Dec 92 04:05:35 GMT
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Lines: 93

In article <[e-mail]> [e-mail] (Eric Koldinger) writes:
>In article <[e-mail]> [e-mail] (Donald Lindsay) writes:
>>I don't think that RPG programmers deal with capabilities, so, the
>>stock microprocessor needs only a stock RPG.
>
>RPG doesn't use the capability features, but OS/400 certainly does.  Don't
>forget that a computer is more than just the applications that it runs.  RPG
>coulde easily be implemented on any machine out there, but you wouldn't call it
>an AS/400.  Just because I can run C on it, I don't call it a PDP-11, eh?

Wanna talk feature-ite-is?  Talk OS/400.

>
>>What other languages are of importance on the AS/400? What is the OS
>>written in, and are capabilities actually explicit at the source
>>level?
>
>Last I checked (4 years ago), the AS/400 supported RPG III, COBOL (I think),
>Pascal, PL/I, and they were coming out with a C compiler.  You don't generally

BASIC, ADA, SQL (Of sorts).

Third Party even a wider variety.  Check Amalgamated Software of North
America for their current list.

>use the capabilities at the applications level, and the languages provide no
>real ability to manipulate capabilities (I've often wondered exactly what C
>ended up looking like on that machine, as pointers and ints are definitely not
>the same, and casting an int to a pointer makes no sense).

Weeeellll,  Depending on what you were doing AS/400 'C' ranges from
bizarre to really bizarre.  What makes no sense is opening a stream.
And reading and writing from the kb/screen is like no 'C' you've ever
programmed before in your life.  Sort of a cross between the RPG and
'C'.  Screen at a time oriented.

>>My experience with software-based capabilites has been positive, so
>>it's not clear to me, offhand, that a stock RS/6000 is out of the
>>question.
>
>There's a fundamental difference between hardware and software capabilities.
>Software capabilities can be forged, however improbable.  For example, Amoeba
>capabilities are just long integers (32, 64 bits?).  You can forge one, but I
>wouldn't bet on it.  Hardware capabilities are secure and cannot be forged.  On
>the AS/400 there is no way to turn an integer into a capability, even for the
>OS (although certain layers of the "microcode" probably can).  Software
>capabilities also do not (efficiently) support the fine grained protection of
>hardware capabilities.  On an architecture like the AS/400, EVERY memory
>reference is checked against a capability, and individual bytes can be
>protected.  Software capabilities are typically used to protect larger grained
>objects, and are only checked when that object is "bound" to your protection
>domain.

This sounds likely, but I avoided going in that deep.  I also have
trouble seeing why it's neccessary, Especially when I keep in mind that
the early releases of OS/400 (v.1 and v.2) crashed for us on a regular
basis just to keep us on our toes.  SCO seems to be more stable and
provide a large portion of the functionality.  There are some security
features I'd like to see implemented that the AS/400 had, but the same
functionality is by no means unobtainable in an *IX enviroment.  In fact
it would not require a whole lot more code IMHO.

What do you mean every memory reference is check against a capability?
What does this mean.  I was under the assumption that the machine model
of the AS/400 is that everything you scribble on or read from lies
somewhere on the terabyte or so of address space in the machine.  This
seems really stupid to me.  Basically then by hiding the hardware in an
address you would *HAVE* to check the memory references for capability,
where if you just treated devices differently from the start you can
avoid this.  In fact you avoid 2 layers, the one at the OS level where
you translate the Device work into a memory reference, and then at the
microcode level where it gets translated *BACK* to some device
operation.  This seemed really silly to me when an IBM SE was telling me
how great it was a couple of years back.  As for process access
faulting and sharing this is available on INTEL CPU's today.  So what
advantage is all of this software layering to *ME* the small business
consumer.  What is *MY* end benifit from all this.

>A stock RS/6000 could certainly run most (all?) AS/400 applications, probably
>faster than an AS/400.  It couldn't, however, (efficiently) support the AS/400
>OS, or the full architectural specification.

Then again,  *WHY* would you WANT to carry all that excess baggage around?

>
>Someone from IBM Rochester might want to correct me if my memory is failing
>here.  Merry Christmas...

Yea, please do.  Straighten me out too!
--
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...