Many ISAs have some sort of xor instruction. The 360 is no different. It offers several different xor instructions which differ in the type of operands that they operate on. In all cases, the operation they perform could be summarized as (using C syntax):

A ^= B;

That is one of the operands is used as both a source and a destination.

There are the boring X (reg ^= memory), XR (reg ^= reg), and XI (reg ^= immediate). Then there is XC which is what inspired this post. XC, or Exclusive Or Character, takes two memory locations and a length and performs what appears as byte by byte xor of the two buffers. (The hardware is smart enough to operate on bigger chunks of memory but the effect is as if it was done byte at a time.) In assembly XC looks like:

XC d1(l,b1),d2(b2)

The d are 12-bit unsigned displacements while the b specify the registers with the base address. For each of the operands the actual address is dX plus the value of the bX register. The l is a length field which encodes a length between 1 and 256.

(This pseudo code ignores the condition code calculation and exception generation which are not relevant to the discussion.)

This by itself is neat but not every exciting…until you remember that xor can be used to zero out a register. You can use XC to zero out up to 256 bytes of memory. It turns out this idiom is used pretty often in handwritten assembly, and compilers such as gcc even produce such instructions without any special effort on the programmer’s behalf.

When I first saw that line in the disassembly of HVF years ago, it blew my mind. It is elegant, fast thanks to the microarchitecture optimizations, and once you are used to the idiom it is clear about what it does. I hope your mind was as blown as mine. Till next time!

A few months ago, I came to the conclusion that it would be both fun and educational to add a new disassembler backend to libdisasm—the disassembler library in Illumos. Being a mainframe fan, I decided that implementing a System/390 and z/Architecture disassembler would be fun (I’ve done it before in HVF).

At first, I was targetting only the 390 and z/Architecture, but given that the System/370 is a trivial (almost) subset of the 390 (and there is a spec for 370 ELF files!), I ended up including the 370 support as well.

It’s been a while since I blahged about mainframes. Rest assured, I’m still a huge fan, I’m just preoccupied with other things to continuously extoll their virtues.

The reason I’m writing today is because it is the 50th anniversary of the System/360 announcement. Aside from the “50 years already?” sentiment, I have a couple of images to share. (I found these several years ago on someone’s GeoCities site. It’s a good thing I made a mirror :) )

Much like VMWARE, they cache the translated code, in z/VOS’s case it’s really a must otherwise I’d guess the cost of traslation would make the result unusable. I like how they used VNC (see the demo mentioned below) to give the virtual x86 box a display.

There is an official blog that has some interesting bits of information. For example, they hint at how they use multiple address spaces to give a the x86 code the illusion of virtual memory. I am not quite sure why they list Decimal Floating Point facility as a requirement. Unfortunately, it has been a few months since the last update.

Their website also happens to have a demo of a small x86 assembly operating system starting up and running under z/VOS. I find this fascinating.

I spend the last few days getting ready for tonight’s presentation. It went rather well. It did take a bit longer then I wanted to, but it was still well within the 2 hour-limit.

For those of you who wanted to come, but didn’t get to, here are my slides. I do realize that it glosses over most things, and sometimes hides some rather important details, but hey…I want to see you summarize over 1200 pages of docs in hour and a half :-P

Once the system is IPLed, it outputs some information to the console, and then continues to idle. While this is not much there is enough code that it lends itself to (aside from my goal with it — see below):

- being used as a basis for experimenting with zArch - being used as the beginning of a toy OS

Since I do not have access to a zSeries and therefore I had to resort to developing and testing on Hercules. It is possible that there are issues that need fixing to get things running smoothly on the real thing.

The ultimate goal is to have a VM/370-like OS that runs on the zArchtecture - to allow Linux and other modern OSes to run concurrently on a single machine. Here are few of the goals on the TODO list:

- nucleus should be all 64-bit (minus the arch mode switching code) - mostly in C - support multiple users - use SIE to virtualize the hardware (S/390 and zArch modes) - give something to the mainframe hobbyist community to play with :)

Note that this is all for the hypervisor — I’d like to have a CMS-like OS as well, but that’s secondary. (In a couple of days, I’m actually planning to post a list of ideas for the guest OS to the HVF mailing list — see below.)

Currently, the list gets commit messages whenever something changes in the repository but I’m hoping that once people join it’ll be more interesting :)

Then there is the IRC channel where you can catch me pretty much all the time:

server: irc.oftc.net (the OFTC network) channel: #hvf

And finally, I have decided to use GPLv2 as the license of choice for the code. The major advantage of doing so is the ability to borrow code (with proper citation of the borrowing) from other GPLv2 projects — namely Linux. The extent of the borrowing is restricted to basic building blocks — e.g., atomic variable types, locking primitives, but not much more beyond that.

I spend most of yesterday reading the x86 Intel books, and the equivalent book for the z/Architecture (by IBM). That alone wouldn’t be much out of the ordinary — what I did with the information gathered was fun. I made a sample, proof of concept harness in C that would do “dynamic” binary translation of zArch machine code to x86_64. (I quoted the word “dynamic” because this test program doesn’t execute the code, it just translates what it is given.)

I took the approach of hand assembling the x86 code, which made things a whole lot slower to develop. For instance, I managed to get most of the zArch AR (Add Registers) translating. The original is a 2-byte instruction, and the resulting x86_64 code is about 40 bytes, and I’m still missing a few bits and pieces.