From: kinch@no11sun.csd.uwo.ca (Dave Kinchlea)
Subject: Re: Tagged Architectures.
Organization: Computer Science Dept., University of Western Ontarioqq
Date: Mon, 13 Apr 1992 02:59:56 GMT
	<1992Apr9.221936.18336@leland.Stanford.EDU>

In article <1992Apr9.221936.18336@leland.Stanford.EDU> jackk@leland.Stanford.EDU (Jack Kouloheris) writes:

>In article <1992Apr9.205334.13216@adobe.com> zalman@adobe.com (Zalman Stern) writes:
>>In article <12383@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris)  
>>writes:
>>> I wonder how much would be involved in making a capability-architecture
>>> version of the POWER instruction set, and using *that* as the underlying
>>> instruction set of an AS/400 model, and whether that could be made
>>> faster than existing models....
>>
>>I heard there is a company that sells an RS/6000 (POWER, whatever you like  
>>to call it) package that emulates a System 36. In more 'mainstream'  
>>terminology it pretty much provides binary compatibility. Binary  
>>compatibility is not precisely correct since there is a level of  
>>interpretation that happens on the native machines as well. This gives one  
>>a lot more lattitude in implementing an emulator.
>>
>>The story I heard was that IBM was pretty unhappy about this product.  
>>(I.e. its price performance against an AS/400 was good enough that people  
>>might actually use it.) I don't follow that realm of the computer business  
>>though so this is totally second hand.
>>
>>--
>>Zalman Stern		>zalman@adobe.com		> (415) 962 3824
>>Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900

As a person who is currently developing such a product, I can attest to its
price/performance as compared to both AS/400 in S/36 emulation mode and a true
System/36. The package I am developing runs on a RS/6000-520, one of the first
available, and runs about 10 times the speed of a AS/400 (but I don't know the
model number). The code *should* port and work nicely under SVR4 on the x86
architecture bring the cost of hardware to a minimum. As for speed, the only
code that needs to be interpreted is the OCL command language. There is a lot
to it but very little real grunt work and so speed is not really an issue (but
we beat the pants off AS/400 response under ALL conditions). The work is done
primarily through Cobol and RPG-II programs and the system routine #GSORT, a
very powerful sort/merge program. 

There are a number of other similar products available, some source code
portable (like ours) and some binary portable (as previously mentioned). I
obviously have my own ideas about which is the *right* way to go but ...

Anyway the point is, it is possible and feasible to provide such an emulation
package (but actually writing one is not as simple as one might think, the
hardest part is supporting undocumented features, of which there are many).
Note also that we do not attempt to offer low-level instruction set
compatibility as it is completely unnecessary for task.


>The System /36 did not have the high-level instruction set of the S/38 and
>the AS/400. It's an older system that evolved from the S/3, S/32, and S/34
>family and was if I remember right, a 16-bit machine. The
>high level instruction set of the S/38 was a break from this family.
>Migration to the AS/400 (and the elimination of most of S/36)
>was provided through recompilation and through providing system and library
>support for the old code. It's not surprising then that it can be efficiently
>supported on the RS/6000 (or other machines, for that matter).

>Jack

cheerskinch
"I think that it would be totally inappropriate      |    Don Mazankowski
for me to even contemplate what I am thinking about."| Deputy PM of Cananda  
	
Newsgroups: comp.arch,comp.ai