I have just found the thread discussing a port of FreePascal to the System/370 and I feel I have to correct some misinterpretations, mistakes and other calumnies that have been thrown into the discussion.  First, my qualifications. I have been a developer of Assembler systems, both applications and systems software since 1981.  I have worked on VS1, MVS (370, XA, ESA), OS/390 and Z/OS systems.  I have worked for many large blue chip companies and for software house (small) and computer manufacturer's (large).

Episode 2.  Inline constants

Firstly, let me explain that there are two different points regarding what has been called "literal" values as concerns S/370 architecture and it's Assemblers. The first of these is called "immediate" values where the literal is included in the actual code generated for that instruction.  The second are called "Literals" and describe unnamed constants that are defined on the instruction that uses them in the source code, but resolve to storage areas that are built into the object deck later.

The "Porting GCC to System/390" document in section 3.1 referred to and other posts state "the original S/390 architecture did not provide instructions that could use literal values as immediate operands".  This is untrue.  Since the System/360 was introduced there was a class of instructions called SI (Storage Immediate) that allowed just that.  The values were however, limited to 1 byte. This has applied to it's descendents (370, 370/XA  390, ESA z/OS and z/OS 64) The 390 extensions in the mid 1990's defined new instructions and extensions to increase this limit to 2 bytes and later to 4 bytes, perhaps, beyond.  I've never worked on the latest 64bit machines so I can't comment.

An example of SI instruction use.

Code            Source                  Comments 92C1 C024       MVI   FIELD,C'A'        Move character A to field. A728 0009       LHI   R2,H'9'           Load 9 into register 2 Note H is a                                        halfword or 16 bit integer value

The code generated is 92C1,C024 where 92 is the opcode, C1 is the character 'A' and C024 is the address in standard base/displacement form.  Or A7 is the opcode, 28 specifies a 32bit load into R2 0009 is the value to load into the register.  LHI is S/390 and later.

An equivalent example of literal instruction use.
D200 C024 C136  MVC   FIELD,=C'A'       Move character A to field. 4820 C134       LH    R2,=H'9'          Load 9 into register 2 Note H is a                                        halfword or 16 bit integer value

The code generated is D200,C024,C136 where D2 is the opcode, C024 is the address of FIELD and C136 the address of the literal, both in standard base/displacement form.  The 00 is data regarding the length of data to move limited from 1 to 256 bytes in this case.  Or 48 is the opcode, 20 specifies the target register (R2) and the optional index register (unused) C134 is the address of the 16 bit value to load in base/displacement form.  Where are the constants?  Well they are generated automatically at the end of the module, or if you wish to define them elsewhere you can include a "LTORG" statement which tells the assembler to define them.

What I would like to know is "Why is this a problem?"  So the constants are defined elsewhere, what issues does this raise?

Are you saying that IN ALL CASES it is completely transparent, and will work with functions of any size, even on e.g. S/390 preceding G5?

My reading of that document- and I stress that I will be very happy to be corrected- is that the assembly source would have to be interrupted every few K for a literal table.

Bear in mind that since FPC generates assembly source code (for whatever target CPU), it might be very inconvenient to interrupt the flow of a large function. And please note that I am being very careful to distinguish here between generic "assembler source" and "IBM Assembler", which as I understand it is a large and complex field with its own culture and conventions (like referring to an "output deck" :-)

Sorry?  Output deck is the output file that the Assembler writes object code to. It used to be on cards, so card deck.  Remember, this stuff was designed 50 years ago. Some of the terminology is like a bad smell.....

You're getting ahead of my notes again! :)  As there isn't a simple yes/no answer to this (is there ever a simple yes/no answer?) Can I defer answering this until episode 3 when I talk about the mystical 4k limit on function or data sizes.

Something to bear in mind though is a) that the differences are more between gas and the IBM assembler (whichever one you use) than between model numbers of processor;  That b) The Porting GCC manual was written by microcode developers.  Lots of stuff that is available to us Assembler programmers is implemented, not in the chip but in microcode.  As such it is available to me but not to them.  and c) IBM have ulterior motives when they restrict the development of GCC to a particular model, they sell processors.  A G5 would fetch a considerable sum. (Cynical? Moi?)