[HN Gopher] Games for IBM AS/400
___________________________________________________________________
Games for IBM AS/400
Author : remoquete
Score : 51 points
Date : 2021-11-26 20:02 UTC (2 hours ago)
(HTM) web link (www.jcrcmds.com)
(TXT) w3m dump (www.jcrcmds.com)
| markus_zhang wrote:
| Considering the power of mainframes, I wonder why there are few
| games made.
| racingmars wrote:
| To be nitpicky -- The AS/400 is not a mainframe, it's what IBM
| calls a "midrange system" positioned between commodity x86
| servers and mainframes. Today, the AS/400 OS (OS/400, or as
| it's known now, IBM i) runs on IBM's POWER servers. For a
| typical IBM i system you're talking a couple 10s of thousands
| of dollars, for a typical mainframe you're in the hundreds of
| thousands.
|
| Also regarding the power of mainframes: in the case of AS/400,
| it's definitely not what I would call fast. Everything runs on
| what is essentially a virtualization layer... the AS/400
| instruction set (MI, or "machine interface") doesn't exist in
| any hardware, it's just run on top of a translation layer on
| top of (these days) POWER. It's a very weird system from top to
| bottom.
|
| As for actual mainframes, traditionally the power came not from
| raw CPU power, but from an architecture that efficiently
| handles parallel I/O. Definitely powerful for batch processing
| of large amounts of data, but not necessarily optimized for
| something like games.
| Yuioup wrote:
| Is AS/400 Open Source?
| skissane wrote:
| > Everything runs on what is essentially a virtualization
| layer... the AS/400 instruction set (MI, or "machine
| interface") doesn't exist in any hardware, it's just run on
| top of a translation layer on top of (these days) POWER
|
| To nitpick your nitpick - MI isn't interpreted, it is
| compiled to machine code. Not JIT, AOT: when you compile a
| program, it actually goes through two steps. First it
| compiles the source code to MI, and saves that in the
| executable (program object). Second, it compiles the MI to
| machine code, and saves that in the executable too, in a
| different section of it. At runtime, the MI is ignored and
| the machine code is run. There is even a command to delete
| the MI part of the executable (called deleting the
| "observability"), and your program will still work after the
| MI is deleting because it isn't actually used at runtime.
|
| When they transitioned from custom CISC [0] to POWER, if you
| still had the MI in your executable, the system would
| automatically recompile it to POWER machine code. If you had
| deleted the observability, it wouldn't run, and you'd have to
| recompile it from source. Theoretically, the same would apply
| if IBM ever decided to move IBM i to some other platform than
| POWER (such as ARM or x86), although I doubt that is ever
| going to happen.
|
| Also, there are actually two versions of MI, old MI and new
| MI. Old MI (OMI) was used with OPM (Original Program Model)
| executables. OMI was the original AS/400 machine interface,
| and is in fact descended from the System/38 machine
| interface. Around the same time they moved to RISC, they
| introduced a new program model (ILE, Integrated Language
| Environment) and new MI (NMI) to go with it. OPM programs
| still run, but now the system translates OMI to NMI, and then
| NMI to machine code. Now, the interesting thing about NMI -
| OMI was indigenous to the 38/400, whereas NMI was actually
| just the internal intermediate language used by IBM's
| compilers on other platforms (such as AIX and OS/2), known as
| "W-code", with some 400-specific extensions. So, in the
| contemporary ILE world, MI is really just a compiler
| intermediate language, like LLVM IR is, and so isn't really
| anything that different from what happens on AIX or Linux or
| Windows or z/OS - the history and the marketing make it sound
| a lot different.
|
| Now, I agree that IBM i isn't necessarily that fast. It has a
| very complex software stack, and while I find that complexity
| fascinating, no doubt it imposes performance costs. But the
| "virtualisation" aspect in itself doesn't cost much at all. I
| think the widespread use of 128-bit pointers is likely a
| bigger issue - although, the 128-bit pointers don't get used
| directly, they get converted to 64-bit pointers before
| actually being used - still that has to have some performance
| cost which other systems don't have to deal with.
|
| But you can opt out of that by running your code in a
| "teraspace", in which case you just use 64-bit pointers and
| the 128-bit pointers are not used. If you are running Java
| code or PASE code (AIX compatibility subsystem), both use
| teraspaces, and if you avoid invoking OS services (as in a
| compute-heavy workload), your performance should be close to
| that of AIX on the same hardware.
|
| [0] the CISC instruction set, IMPI, was inspired by the 370
| instruction set but not compatible with it. For AS/400, I
| don't believe it has ever been publicly documented, but I'm
| led to believe the 400 CISC instruction set was just an
| evolution of the 38 CISC instruction set, which was publicly
| documented in this manual: http://www.bitsavers.org/pdf/ibm/s
| ystem38/SC21-9037-3_IBM_Sy...
| Aloha wrote:
| I've often considered AS/400 a "road not taken" in systems
| engineering, one that would have been much more influential
| had it come out 15 years sooner (though if it had, the
| hardware would not have been performant enough to run it),
| particularity the abstraction between memory and storage
| being handled by the OS rather than the application. The
| machine independent codebases, and other features and
| bonuses and have allowed it to continue to live on at
| minimal cost.
| skissane wrote:
| One of the big problems I see with 38/400, is while it
| had some very innovative features, it also had some very
| old-fashioned ones: EBCDIC, COBOL, RPG, etc. IBM has de-
| emphasised those old-fashioned aspects over time, but
| maybe it would have been more successful if they'd moved
| away from them at the start?
|
| I think it also might have been more successful if
| instead of porting it to POWER they'd ported it to x86 -
| they might have needed to add some tagged memory
| extension to x86 to do that, but I'm sure Intel would
| have been happy to talk. Indeed, the same idea has a
| history in Intel, if you look at the iAPX-432 and the
| i960, so Intel would certainly have understood the
| request-they might have even been excited about it. (Of
| course, given IBM's commitment to RISC and POWER, wasn't
| going to happen.)
|
| Like a lot of other IBM systems, it became more closed
| over time. The System 38 had huge amounts of very
| detailed technical documentation publicly available. With
| the AS/400, much of those details moved under NDA, and it
| has only got worse over time. Now, you can't even write a
| compiler for (non-PASE) AS/400 without signing an IBM
| NDA, the executable format is under NDA. How closed is
| that!
|
| I even wonder, what if instead they'd ported 400 to
| 370/390/z, or tried to make 38/400 and 370 more
| compatible from the start? Maybe some of these ideas
| might have cross-pollinated to MVS/VM/etc. A lot of what
| is most original about the 38 and 400 (single-level
| store, capability-based addressing) actually descends
| from the Future Systems project, a cancelled 1970s effort
| to design a next-generation successor to the 360/370.
| Maybe these those technologies might have been more
| influential if they had a future on the mainframe? A
| merger of the AS/400 and 9370 lines could have led to
| that.
| trasz wrote:
| Does that mean part of the compiler is security-critical?
| monocasa wrote:
| I don't think the parent said that it's interpreted, only
| that it sits on a translation layer which is true.
| skissane wrote:
| Oh yes. But the parent made it sound like having a
| "translation layer" makes it somehow unique. Contemporary
| IBM i, the "translation layer" is a modified form of
| compiler intermediate language copied from IBM's AIX/etc
| compilers, and as such isn't really fundamentally
| different from what happens on other platforms. It also
| made it sound like the translation layer had a
| performance cost - in itself, it doesn't, any more than
| LLVM IR has a performance cost. Some of the entities the
| bytecode/IR allows you to manipulate - such as 128-bit
| pointers - likely have some cost, but that is a cost of
| those entities, not of having a bytecode/IR in itself.
|
| Not saying there is nothing unique about AS/400. The
| single-level store is a big one, although in more recent
| decades there has been a big move away from it
| (teraspaces, PASE, migration from Classic to J9 JVM).
|
| I think the history of 38/400/i could be described like
| this: it started out with some very innovative, even in
| some way alien ideas - capability addressing, single
| address space single-level store, having a bytecode (as
| opposed to the real hardware's assembly language be the
| public interface to the OS), primitive object-orientation
| backed into the OS, a relational database embedded in the
| operating system (although how deeply integrated it
| really is has never been that clear), etc. At the same
| time, it mixed that up with some far less innovative
| traditional IBM technologies - COBOL, RPG, EBCDIC, block
| mode terminals, SNA, etc - so even from the start it was
| some odd hybrid of cutting-edge and trailing-edge ideas.
| But, gradually since, it has been moving away from that
| odd mix towards become a much more mainstream system.
| While the old MI bytecode was a public interface, the new
| MI bytecode documentation is only available under NDA,
| and is basically the same as IBM's proprietary compiler
| intermediate representation on their other platforms. The
| single address space single-level store exists, but now
| programmers are encouraged to run their code in a more
| traditional separate address architecture (teraspace)
| instead. With the move to POWER, an AIX compatibility
| subsystem (PASE) was introduced, and more and more code
| was ported from AIX - and more recently open source
| packages from Linux. Java was ported to it, and
| programmers were encouraged to develop in Java - and
| while IBM's original AS/400 JVM, the "Classic JVM",
| integrated Java with the original AS/400 single address
| space world, at some point it was replaced by a port of
| IBM J9 from AIX running in a teraspace, and now it really
| behaves no differently than J9 on any other platform
| does. It is a system which started out as a weird hybrid
| of the innovative and the traditional, but which has been
| gradually evolving to be come more and more mainstream,
| without dropping the backward compatibility necessary to
| support that original weird hybrid.
| kej wrote:
| I would imagine there's a lot of overlap between places that
| use mainframes and places where anything unauthorized, let
| alone games, will get you fired.
| 123pie123 wrote:
| many moons ago, I was lucky enough to have root (QSECOFR)
| access and treat the box as my personal play thing - even
| while running prod stuff.
|
| we could have put games on it, if we trusted the developer -
| well may be just the dev server.
|
| Windows NT 4 and Windows 3.11 was more interesting at the
| time with AOL dial up access
| ASalazarMX wrote:
| Definitely any company that could afford a (then) AS/400
| wouldn't look kindly on using it for gaming.
|
| That being said, some did, otherwise these little games
| wouldn't exist. At one of my previous jobs, the end of the
| year was boring, no clients and projects would be on hold
| until January. One of those years I wasted a week making a
| crude reversi game complete with CPU player, and it was well
| received among the other programmers.
|
| We tried to make a checkers game, but turns out a checkers
| CPU player is a lot harder than reversi for business
| programmers.
| markus_zhang wrote:
| Agreed, that's my thought too.
___________________________________________________________________
(page generated 2021-11-26 23:00 UTC)