[jonnycowboy]

The thing is that there was a lot about those old systems that was slow, so you were very, very careful how you programmed. You tended not to use vast library stacks, you went close to the metal and you coded in languages like Assembler, COBOL or FORTRAN. I/O was often run through specialised co-processors (such as IBM's channel processors) and the terminals could sometimes help too.

I have friends who have been looking after legacy applications for an airline running on Unisys. The core apps for reservation, Cargo booking and weight/balance were written in FORTRAN. In recent times, the front end was written in Java to give web access. They tried to rewrite the core apps but it was impossible to do so and get the performance.

[YeGoblynQueenne]

>> They tried to rewrite the core apps but it was impossible to do so and get the performance.

Well, Cobol is a bit like the C of mainframes - you can manipulate memory directly and so on. You can't really do that sort of thing with Java.

[stefs]

a) if it was really running on the old hardware; in that case ruby on a modern machine would have been several magnitudes faster than the original code - at least because of the faster IO

b) if the whole thing was indeed running in an emulator, the emulation overhead would have negated all direct memory access advantages

[wahern]

Emulators on mainframes are much more sophisticated and performant than is typical on x86 and ARM platforms. The hardware and even software is often designed with emulation in mind, not just for backwards compatibility but for forwards compatibility, too.

[andai]

Do you mean to say that they were running a mainframe emulator on a mainframe?

[wahern]

Compilers for some IBM mainframes have for decades (since the 1970s, I think) targeted an intermediate virtual machine instruction set which is then translated on-the-fly to the local architecture by the OS upon execution. So in the case of IBM their machines are truly built with both forward and backward compatibility in mind. The pointers for this instruction set have been 128 bits since the beginning, long before 64-bit hardware even came into being.

Some (or all?) of the latest Unisys mainframes run on Intel Xeons, but with custom chips for translating the machine code of their old architectures.

I don't work in this area. I just like reading about it. Though, unfortunately, it's difficult to find clear specifications and descriptions on how these architectures work.

For example, Unisys' 2200 ClearPath architecture is one of the (if not _the_) last architectures still sold that uses signed-magnitude representation, as well as having an odd-sized integer width of 39 bits. (INT_MAX is 549755813887 and INT_MIN is -549755813887, and the compiler has to "emulate" the modulo arithmetic semantics required of unsigned types in C. ClearPath MCP is also a POSIX system, and has to emulate an 8-bit char type.) I discovered that you could download the specification for their C compiler for free online, which was useful when discussing the relevancy of undefined behavior in C. But AFAIU (and this is where finding concrete details is more difficult) the latest models of the ClearPath line use Xeons with custom chips bolted on to help run the machine code of the older architecture. In any event, the point is that while the old architecture is arguably emulated, it's not a pure software emulation that you might assume, and the resulting performance is better than the previous models of those mainframes, which were still being built at least until a few years ago. In other words, direct memory access isn't ruled out because the I/O systems may have been intentionally designed to work efficiently in a backwards compatible manner.

[dfox]

The 128bit pointer intermediate code is used on what IBM calls "midrange systems" (ie. AS/400), not mainframes. IBM mainframes execute their machine code directly and the ISA is designed such that it allows for efficient virtualization since beginning and is extensible and backwards-compatible. Otherwise the IBM mainframe magic is in IO offload and truly immense memory bandwidth. On the other hand, Unisys systems use architecture that is significantly different from what today's programmer would expect, with completely different memory model originally implemented in hardware (which essentially combines the memory protection model implemented on AS/400 in software with lisp machine-style pointer tagging).

[abakker]

Excellent comment. I'll also point out that system z mainframes are not slow machines, so even with some emulation overhead there is typically enough performance.

[vidarh]

Yes, but good luck translating any sizeable chunk of code to a higher level language without a massive effort figuring out which things are discarded side-effects that can be ignored and which things are relied on later. I just spent a few hours last night massaging a C-translation from 6502 assembler. It's a tiny piece of code - ~3000 lines that'll probably shrink to ~2500 or so as I figure out which results are ignored (the original translation attempted to do a faithful 1-1 translation instruction by instruction, which leads to things like long sequences to handle basic multiplication etc.), but it takes ages, because it is not always obvious when it e.g. depends on the status flags set, and values keep being moved between registers etc. Now try doing that with a big piece of code.

There's a reason why people often resort to emulators.

[eru]

> The thing is that there was a lot about those old systems that was slow, so you were very, very careful how you programmed.

That's a common sentiment. I wish I could find the quote by someone who made the transition; it was about how happy they were to be able to compile so much quicker, and how getting immediate feedback made them so much more productive.

[3n7r0pY]

The notion of waiting ages for programs to compile or assemble is mostly related to the older hardware.

I compile/assemble COBOL and IBM's assembly language on a z13 daily and it's pretty much instantaneous.

[eru]

> The notion of waiting ages for programs to compile or assemble is mostly related to the older hardware.

Oh, I was talking more about older ways to organize the data centre: batch vs timeshare processing.

https://en.wikipedia.org/wiki/Time-sharing