joel@cfctech.cfc.com (Joel Lessenberry) (02/28/90)
During the announcement, and several times after, IBM has
pointed out that the processor in the low end AS/400
systems is different than the processor in the rack mount
systems...in fact that low end systems is RISC based.
Could this RISC be similar to the System/6000?
joel
Joel Lessenberry, Distributed Systems | +1 313 948 3342
joel@cfctech.UUCP | Chrysler Financial Corp.
joel%cfctech.uucp@mailgw.cc.umich.edu | MIS, Technical Services
{sharkey|mailrus}!cfctech!joel | 2777 Franklin, Sfld, MI
geoff@edm.uucp (Geoff Coleman) (02/28/90)
From article <20714@cfctech.cfc.com>, by joel@cfctech.cfc.com (Joel Lessenberry): > > During the announcement, and several times after, IBM has > pointed out that the processor in the low end AS/400 > systems is different than the processor in the rack mount > systems...in fact that low end systems is RISC based. > > Could this RISC be similar to the System/6000? > > joel > > > Joel Lessenberry, Distributed Systems | +1 313 948 3342 Actually this is about the first posting I've seen which mentions both the AS/400 and the 6000. So far I have found it interesting that everybody seems to be concentrating on this box as a workstaion. What are the possibilities for it in the small number (ie. < 32) of user arena? It would seem to me that IBM just may have introduced an AS/400 killer. From my understanding the MCA bus should support Intelligent ports cards a bit better than the (E)ISA bus (it certainly can't be any worse). What are other peoples comments on this subject Geoff Coleman Unexsys Systems
kolding@cs.washington.edu (Eric Koldinger) (02/28/90)
In article <20714@cfctech.cfc.com> joel@cfctech.cfc.com (Joel Lessenberry) writes: > > During the announcement, and several times after, IBM has > pointed out that the processor in the low end AS/400 > systems is different than the processor in the rack mount > systems...in fact that low end systems is RISC based. > > Could this RISC be similar to the System/6000? No. In fact, if I remember correctly, all of the various AS/400 models have microcode (what IBM calls HMC, or horizontal microcode), so none of them would qualify as RISC based at any level. They also all have substantial OS support, called VMC, or vertical microcode. -- _ /| Eric Koldinger \`o_O' University of Washington ( ) "Gag Ack Barf" Department of Computer Science U kolding@cs.washington.edu
johnl@esegue.segue.boston.ma.us (John R. Levine) (03/01/90)
In article <1990Feb28.042949.21952@edm.uucp> geoff@edm.uucp (Geoff Coleman) writes: > Actually this is about the first posting I've seen which >mentions both the AS/400 and the 6000. ... >It would seem to me that IBM just may have introduced an AS/400 killer. From my understanding of the AS/400, based on some frustratingly vague articles in the IBM Systems Journal last year, the AS/400 has a multi-level virtual architecture. In particular AS/400 "executable" files are in fact in a virtual microcode that is compiled to the native microcode at the time the program is loaded. Different models of the AS/400 can and do have different native microcodes. I see no reason why they couldn't use the 6000's processor as such an engine, though to implement the AS/400's enormous single level address space you'd probably want a different memory mapper than the 801-like one that they use now. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl "Now, we are all jelly doughnuts."
kolding@cs.washington.edu (Eric Koldinger) (03/01/90)
In article <1990Feb28.174838.7725@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes: >In article <1990Feb28.042949.21952@edm.uucp> geoff@edm.uucp (Geoff Coleman) writes: >> Actually this is about the first posting I've seen which >>mentions both the AS/400 and the 6000. ... >>It would seem to me that IBM just may have introduced an AS/400 killer. > >From my understanding of the AS/400, based on some frustratingly vague >articles in the IBM Systems Journal last year, the AS/400 has a multi-level >virtual architecture. In particular AS/400 "executable" files are in fact >in a virtual microcode that is compiled to the native microcode at the time >the program is loaded. Yes, somewhat. Some programs are translated to IMPI, the internal machine language, which is interpreted by HMC, or what most people would call microcode. Others are left at the MI, or machine interface, which is the same as the S/38 MI (and assembly language), I believe. >Different models of the AS/400 can and do have >different native microcodes. I think they all run the same micro-code. At least they all run the same VMC (vertical microcode). >I see no reason why they couldn't use the 6000's >processor as such an engine, though to implement the AS/400's enormous >single level address space you'd probably want a different memory mapper >than the 801-like one that they use now. The AS/400 uses 48-bit addresses, so you'd have to add 48-bit addressing registers to the architecture (or convert the register file to 48 bits). Also, the AS/400 uses a tagged memory system to support it's capability's, and does a lot of the capability checking in hardware, not software. You'd need to add support for this also, or lose performance. I highly doubt that they'll use the America chip the AS/400. -- _ /| Eric Koldinger \`o_O' University of Washington ( ) "Gag Ack Barf" Department of Computer Science U kolding@cs.washington.edu
sysmgr@KING.ENG.UMD.EDU (Doug Mohney) (03/02/90)
> Actually this is about the first posting I've seen which >mentions both the AS/400 and the 6000. So far I have found it interesting >that everybody seems to be concentrating on this box as a workstaion. What >are the possibilities for it in the small number (ie. < 32) of user arena? >It would seem to me that IBM just may have introduced an AS/400 killer. >From my understanding the MCA bus should support Intelligent ports cards >a bit better than the (E)ISA bus (it certainly can't be any worse). Three words come into play here: Installed Software Base If it is worth the time/trouble to port business software running on the AS/400 series to the RISC box, sure. I'm not sure if there is a COBOL compiler for the 6000 series yet, however :-) More interesting; IBM also announced a 370 box with MicroChannel which had '386 chips handling I/O. **************************************************************** Should you look at DEC equipment (gasp), you find that a VAXstation 3100 and a DECstation 3100 cost about the same, but the DECstation gives you anywhere from 2-3 times performance in any given situtation. Why should you stick with VAX VMS, even tho' you get more bang for the buck out of a DEC station? Doug
billms@dip.eecs.umich.edu (Bill Mangione-Smith) (03/02/90)
In article <0093307E.0B7FBDC0@KING.ENG.UMD.EDU> sysmgr@KING.ENG.UMD.EDU (Doug Mohney) writes: >>It would seem to me that IBM just may have introduced an AS/400 killer. > >Three words come into play here: > > Installed Software Base > Just what is the installed software base on the as/400? Thats a reasonably new machine, isn't it. We are not talking decades here. >AS/400 series to the RISC box, sure. I'm not sure if there is a COBOL >compiler for the 6000 series yet, however :-) Yep, we've had one here on our 600 for some time now. Not that I'd ever want to use it. Don't think anybody else has either.... >Why should you >stick with VAX VMS, even tho' you get more bang for the buck out of a >DEC station? > > Doug Because VMS has had people writing code for it for a long time. Because people have been using VMS for a long time. Because businesses have been buying VMS stuff for a long time. The same is true of UNIX. Is it also true of the as/400? I don't know. What operating system does it use? Bill Mangione-Smith billms@dip.eecs.umich.edu
grunwald@foobar.colorado.edu (Dirk Grunwald) (03/02/90)
>>>>> On 1 Mar 90 18:12:29 GMT, sysmgr@KING.ENG.UMD.EDU (Doug Mohney) said:
...
DM> If it is worth the time/trouble to port business software running on the
DM> AS/400 series to the RISC box, sure. I'm not sure if there is a COBOL
DM> compiler for the 6000 series yet, however :-)
----------
guess again. Someone I know has a pre-release model. No fortran, but
it does have cobol. I think they have an Ada compiler as well.
DM> More interesting; IBM also announced a 370 box with MicroChannel which
DM> had '386 chips handling I/O. terry@uts.amdahl.com (Lewis T. Flynn) (03/02/90)
In article <1586@zipeecs.umich.edu> billms@eecs.umich.edu (Bill Mangione-Smith) writes: >In article <0093307E.0B7FBDC0@KING.ENG.UMD.EDU> sysmgr@KING.ENG.UMD.EDU (Doug Mohney) writes: >>>It would seem to me that IBM just may have introduced an AS/400 killer. >> >>Three words come into play here: >> >> Installed Software Base >> > >Just what is the installed software base on the as/400? Thats a reasonably >new machine, isn't it. We are not talking decades here. S/36 and S/38 applications ported fairly directly (if you believe the third party vendors who were at the announcement: "Why, my application ported in 43 seconds" or whatever). There are LOTS of those. More knowledgable folks can tell you why this is good (for an AS/400 user). Terry #include <disclaimer.std>
gerry@zds-ux.UUCP (Gerry Gleason) (03/03/90)
In article <0093307E.0B7FBDC0@KING.ENG.UMD.EDU> sysmgr@KING.ENG.UMD.EDU (Doug Mohney) writes: >Should you look at DEC equipment (gasp), you find that a VAXstation 3100 >and a DECstation 3100 cost about the same, but the DECstation gives you >anywhere from 2-3 times performance in any given situtation. Why should you >stick with VAX VMS, even tho' you get more bang for the buck out of a >DEC station? It doesn't make much sense to me, except as you said earlier: > Installed Software Base But obviously it meets someone's needs, or they wouldn't be selling any (I assume they are, or they won't be sold for long). Of course, nobody in their right mind would pick the VAXstation over the DECstation when the majority of the project is new development, but who ever claimed that most customers are in their right mind ;-). Gerry Gleason
sysmgr@KING.ENG.UMD.EDU (Doug Mohney) (03/03/90)
>Just what is the installed software base on the as/400? Thats a reasonably >new machine, isn't it. We are not talking decades here. AS/400 runs System/370 code or System/36 code or something which was previously supposed to be the ballpark of one of IBMs Other Machines, as well as have some unique applications all its own. >Yep, we've had one here on our 600 for some time now. Not that I'd ever >want to use it. Don't think anybody else has either.... Yes, I saw that they do actually have COBOL (eek!) for the 6000 series. Pretty perverted, actually...Businesses will actaully love it when you get something like dBase on it. > >>Why should you >>stick with VAX VMS, even tho' you get more bang for the buck out of a >>DEC station? >> >> Doug > >Because VMS has had people writing code for it for a long time. Because >people have been using VMS for a long time. Because businesses have been >buying VMS stuff for a long time. The same is true of UNIX. Yes, but how long are you going to continue to pay for VMS, get SCREWED by Digital on VMS licensing agreements, and pay for boxes which are two to three times slower for the same dollar amount? Not to mention peripherials which cost significantly more than what you can find in an "open" systems such as Suns.
wayne@teemc.UUCP (//ichael R. //ayne) (03/03/90)
In article <00933154.7F943660@KING.ENG.UMD.EDU> sysmgr@KING.ENG.UMD.EDU (Doug Mohney) writes: > >Yes, but how long are you going to continue to pay for VMS, get SCREWED by >Digital on VMS licensing agreements, and pay for boxes which are two to three >times slower for the same dollar amount? > >Not to mention peripherials which cost significantly more than what you can >find in an "open" systems such as Suns. Posted by someone who has NO understanding of the power of marketing. I know of companies that do that and persist in telling you how much better off they are than if they had to use that "horrible Unix operating system". I don't claim to understand HOW they do it, but it gets done. /\/\ \/\/ -- Michael R. Wayne --- TMC & Associates --- wayne@teemc.uucp INTERNET: wayne%teemc.uucp@sharkey.cc.umich.edu uunet!edsews!teemc!wayne Operator of the only 240 Horsepower UNIX machine in Michigan
guy@auspex.auspex.com (Guy Harris) (03/04/90)
> Yes, somewhat. Some programs are translated to IMPI, the internal machine > language, which is interpreted by HMC, or what most people would call > microcode. Others are left at the MI, or machine interface, which is the > same as the S/38 MI (and assembly language), I believe. > >>Different models of the AS/400 can and do have >>different native microcodes. > > I think they all run the same micro-code. At least they all run the same > VMC (vertical microcode). OK, so is VMC code that, in executable form, is in IMPI? In that case, are you saying that the IMPI is the same on all the models? In that case, is there any reason (other than "it doesn't match what IBM calls them") not to call the HMC "the microcode", the VMC "machine language code", and the MI "some tokens in some interpretive language that sometimes gets compiled into machine code"? Or, to put it another way, how is this different from, e.g., the trick of, say, compiling Smalltalk bytecodes into machine code and caching the compiled bytecodes, with perhaps some bytecodes being interpreted rather than compiled?
drake@sd2.almaden.ibm.com (Sam Drake) (03/04/90)
In article <1586@zipeecs.umich.edu> billms@eecs.umich.edu (Bill Mangione-Smith) writes: >Just what is the installed software base on the as/400? Thats a reasonably >new machine, isn't it. We are not talking decades here. Well, maybe not decades, but a long, long time. The AS/400 is relatively new, but as it's upwardly compatible with System/36 and System/38 there are a LOT of AS/400s and a LOT of programs available for them. Opinions are my own. Sam Drake / IBM Almaden Research Center Internet: drake@ibm.com BITNET: DRAKE at ALMADEN Usenet: ...!uunet!ibmarc!drake Phone: (408) 927-1861
kolding@cs.washington.edu (Eric Koldinger) (03/04/90)
In article <2984@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
:: Yes, somewhat. Some programs are translated to IMPI, the internal machine
:: language, which is interpreted by HMC, or what most people would call
:: microcode. Others are left at the MI, or machine interface, which is the
:: same as the S/38 MI (and assembly language), I believe.
::
:::Different models of the AS/400 can and do have
:::different native microcodes.
::
:: I think they all run the same micro-code. At least they all run the same
:: VMC (vertical microcode).
:
:OK, so is VMC code that, in executable form, is in IMPI?
Yes. Much of it is essentially OS code, although it's part of the
published architecture. All VMC runs at the IMPI level.
:In that case, are you saying that the IMPI is the same on all the
:models?
As far as I know, yes. At least I think that this is the case currently.
There is nothing that prevents the IMPI specification from being changed.
Only the MI must remain stable.
:In that case, is there any reason (other than "it doesn't match what IBM
:calls them") not to call the HMC "the microcode", the VMC "machine
:language code", and the MI "some tokens in some interpretive language
:that sometimes gets compiled into machine code"?
The problem with breaking it down this way is that IMPI can essentially
be thought of as a moving target. The MI is the published architecture,
and all future AS/400's will conform to MI. However, the IMPI can change
quite radically. All programs that are written at MI level will continue
to run, even if they were translated from MI to IMPI (the os will take care
of automatically retranslating them).
--
_ /| Eric Koldinger
\`o_O' University of Washington
( ) "Gag Ack Barf" Department of Computer Science
U kolding@cs.washington.edusysmgr@KING.ENG.UMD.EDU (Doug Mohney) (03/06/90)
In article <103335@teemc.UUCP>, wayne@teemc.UUCP (//ichael R. //ayne) writes: >In article <00933154.7F943660@KING.ENG.UMD.EDU> sysmgr@KING.ENG.UMD.EDU (Doug Mohney) writes: >> >>Yes, but how long are you going to continue to pay for VMS, get SCREWED by >>Digital on VMS licensing agreements, and pay for boxes which are two to three >>times slower for the same dollar amount? >> >>Not to mention peripherials which cost significantly more than what you can >>find in an "open" systems such as Suns. > > Posted by someone who has NO understanding of the power of marketing. Actually, I do understand marketing; up until now, DEC has been able to get away with their policies because they offered roughly equilivant price/performance specs; RISC boxes running Ultrix are going to change the way DEC and IBM does business. It isn't going to happen overnight, but the RS/6000 is going to slowly chip away at AS/400 sales and the DECstation 3100 will poach off VAXstation 3100 sales. >I know of companies that do that and persist in telling you how much >better off they are than if they had to use that "horrible Unix operating >system". As UNIX becomes more popular, software like NeXT step and SunTools will be used to frost the user-hostile UNIX interface, so no one except a programmer will have to see the nastiness of a C-shell.
guy@auspex.auspex.com (Guy Harris) (03/06/90)
>:OK, so is VMC code that, in executable form, is in IMPI? > > Yes. Much of it is essentially OS code, although it's part of the > published architecture. All VMC runs at the IMPI level. So what language is the OS written in? Assembler (i.e., something that translates fairly one-to-one to IMPI)? RPG or Cobol or one of the other languages that compiles into MI, with the MI then being statically compiled into IMPI? > The problem with breaking it down this way is that IMPI can essentially > be thought of as a moving target. The MI is the published architecture, > and all future AS/400's will conform to MI. However, the IMPI can change > quite radically. All programs that are written at MI level will continue > to run, even if they were translated from MI to IMPI (the os will > take care of automatically retranslating them). So you then think of System/38 and AS/400 as being a set of machines with potentially binary-incompatible instruction sets, but that all run compatible interpreters/MI compilers.... Perhaps this is sort of like moving Smalltalk bytecodes between different machines with different underlying processors. So how come if the IMPI *can* change, it *hasn't* changed? (*Did* they write the OS in assembler language? :-))
mrm@sceard.Sceard.COM (M.R.Murphy) (03/07/90)
In article <2989@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes of IMPI [details omitted for brevity, the soul of wit...] >So you then think of System/38 and AS/400 as being a set of machines >with potentially binary-incompatible instruction sets, but that all run >compatible interpreters/MI compilers.... Perhaps this is sort of like >moving Smalltalk bytecodes between different machines with different >underlying processors. If it walks like an interpreter, sounds like an interpreter, and has feet like an interpreter, it's an interpreter. I like EDL, myself :-) Seems to me that it doesn't matter much where the interpreter lives, if it results in more time spent to process data, then it's slower, and, therefore, more costly. Blatant tautology time. Then again cost to someone is income to someone else. Having stated the thought in the paragraph above, are there interpreters, hard, firm, or soft, that result in reduced processing times? Just curious. -- Mike Murphy Sceard Systems, Inc. 544 South Pacific St. San Marcos, CA 92069 mrm@Sceard.COM {hp-sdd,nosc,ucsd,uunet}!sceard!mrm +1 619 471 0655