Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in


base+displacement addressing scheme

Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> PL/I & Assembler
View previous topic :: :: View next topic  
Author Message

Active User

Joined: 09 Jun 2014
Posts: 105
Location: windsor

PostPosted: Tue Mar 03, 2015 2:07 am    Post subject: base+displacement addressing scheme
Reply with quote

Hi All,

I just start to learn assembler and come cross this term base+displacement addressing , so why we need address to be base +displacement ?

Also can you give me some suggestion on how to start the assembler ?
Any mainframe assembler book i can start with ?

Back to top
View user's profile Send private message


Active User

Joined: 30 Nov 2013
Posts: 455
Location: The Universe

PostPosted: Tue Mar 03, 2015 6:35 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Paul Voyner

New User

Joined: 26 Nov 2012
Posts: 51
Location: Switz

PostPosted: Wed Mar 04, 2015 12:49 pm    Post subject:
Reply with quote

Try these


Back to top
View user's profile Send private message

Active User

Joined: 30 Nov 2013
Posts: 455
Location: The Universe

PostPosted: Thu Mar 19, 2015 12:47 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> PL/I & Assembler All times are GMT + 6 Hours
Page 1 of 1


Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts DFHCOMMAREA addressing akodakka CICS 4 Fri May 30, 2014 5:17 pm
No new posts JOINKEYS or SPLICE? while retaining h... hsinaz50 DFSORT/ICETOOL 4 Thu Apr 17, 2014 12:13 am
No new posts VSAM AIX is not populating base clust... Satheeshkumar JCL & VSAM 2 Sun Oct 20, 2013 9:32 am
No new posts URGENT To copy GDG base with gens wit... ranjitbhingare DFSORT/ICETOOL 8 Thu Apr 04, 2013 6:47 am
No new posts Can we use SYMBOLIC parameter as last... Adhiraj_Singh JCL & VSAM 9 Mon Sep 17, 2012 4:25 pm

Back to Top
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us