Joined: 30 Nov 2013 Posts: 917 Location: The Universe
The primary reason for base register + displacement is to express a storage address in as few bits as possible.
I started with the IBM 7040. Each 36-bit instruction specified one or sometimes two 15 bit addresses. There were two problems with this scheme.
15 bits limited you to 32K words of addressability. This scheme was devised in the 1950s; by the early 1960s it was clear much larger storage sizes would be available.
There were no relocatable programs as they are understood today. Most programs were loaded from object decks by a linking loader. If you knew what to look for - and when - you could see the linking loader relocate the addresses in the instructions. Yes, it was that slow!
Base register + displacement lets you specify an address in 16 bits: 4 bits to specify a register and 12 bits to specify the displacement. A register contained 32 bits, so you potentially had 4 gig of addressability in the register plus 4K in the displacement. The 12-bit displacement stayed fixed; you could achieve full relocatability much more easily. This worked pretty well into the 1990s - not bad, really.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
I just want to expand my earlier post a bit.
In 1954 (when the IBM 704 was introduced, along with the addressing scheme used in the 709, 709x and 704x computers), 32K words seemed like infinity compared to earlier computers, where “fast” storage was in hundreds of words or less. This huge amount of storage provided room for the first Fortran compiler, as well as other advanced (for the time) programs.
I took a quick look at the books Mr. Voyner listed.
I was aware of the Bill Qualis book, but had never looked at it in detail. It has one very fundamental problem. It refers to a product called PC/370. PC/370 is no longer readily available, and it might prove difficult to run. PC/370 is a 16-bit DOS program. It will run in a command window in Windows XP, but it will not run in Windows Vista, Windows 7 or Windows 8. It has been effectively replaced by a Java based product called z390. z390 was written by the same people that produced PC/370. From what little I know about it it seems to be a significant advance over PC/370. I have never used it. Many people in this forum have used it and seem to think well of it, though it has been a long time since there has been a post regarding it use in this forum. Use Google to locate it.
I do not believe I ever encountered the Edward Bosworth book.
The “IBM S/360 Heritage” chapter, while very brief, appears reasonably accurate.
In my opinion, the “Handling Floating Point Data” and “Conversions for Floating Point Formats” chapters are entirely unnecessary. Assembler programmers rarely, if ever, use floating point data.
The “Writing Macros” chapter is, in my opinion, very poor. The first problem is Mr. Bosworth appears fixated on the idea that the stack concept used in many computer architectures should be stuck onto System/360. This fixation continues with the remainder of the book. The stack concept is useful in architectures with few registers, such as the Intel 80x86. It is less useful in System/360 with a large number of registers. The stack concept effectively uses storage in place of registers.
In my opinion, the “Subroutine Linkage” chapter is poorly organized and illustrates Mr. Bosworth's inability to understand some basic concepts, or perhaps he is attempting to insert C concepts into the Assembler, where the C concepts are not used by Assembler programmers. The discussion of the CALL macro parameter list is plain wrong. Mr. Bosworth is correct in criticizing static save areas, but he probably does not understand many programmers (and essentially all ISV products) have abandoned this concept and use more dynamic save areas, at least for internal use.
Mr. Bosworth points out that Assembler lacks the block structure in most “modern” languages, even “primitive” languages like C. This is true, but Assembler programmers can – and should – structure their programs so they are more understandable to other programmers (or you, if you come back to a program after an extended period of time). Many years ago my friend Bill Mosteller proposed that the target of an Assembler branch instruction should be “higher” in a listing only if it forms a loop. The effect of following Mr. Mosteller's proposal is a very block structured program.
Well, good luck. The IBM System/360 was designed to be friendly to Assembler programmers, much more so than more “modern” hardware, and this is still true with z/Architecture systems. Not only is the hardware easy to understand, but System/360 Assemblers were designed with a sophisticated macro processor, coupled with a wide range of system provided macros that greatly ease program development for an Assembler programmer. After you are used to the concepts and learn the more commonly used instructions and system macros, I think you will find System/360 Assembler is comparable to C (not C++).
Unfortunately, there is nothing in Assembler comparable to the C standard library of external functions other than the data management macros.
