| Re: IBM S/360 - 370 [message #396045 is a reply to message #396025] |
Mon, 22 June 2020 11:47   |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
robin.vowels@gmail.com writes:
> On Monday, June 22, 2020 at 2:52:52 PM UTC+10, Dan Espen wrote:
>> r......@gmail.com writes:
>>
>>> On Monday, June 22, 2020 at 11:53:42 AM UTC+10, Jon Elson wrote:
>>>> r.......@gmail.com wrote:
>>>>
>>>> > On Friday, July 25, 2014 at 6:52:05 AM UTC+10, Jon Elson wrote:
>>>> >
>>>> >> The 370 series was a practical architecture, although the performance
>>>> >> of some of the lower models seems like it must have been intentionally
>>>> >> crippled to not interfere with the /15x and /16x machine.
>>>> >
>>>> > What do you mean, "practical architecture"?
>>>> >
>>>> > While it has some exotic instructions (such as EDMK, TR, TRT etc),
>>>> > it lacked practical or useful instructions such as:
>>>> >
>>>> > Increment a binary integer
>>>
>>>> Acttually, I think you can use the load address instruction to do this.
>>>
>>> No.
>>> LA requires that the result be only 24 bits, and that the result be positive.
>>> Anything above that is truncated.
>>> And it does not set the condition code, so it's worthless for
>>> that purpose.
>>
>> In 31 bit mode, LA is 31 bits.
>> In 64 bit mode, LA is 64 bits.
>
> These were all afterthoughts.
>
>> Current machines have a bunch of add immediate instructions.
>>
>> Current machines even have a stack.
>
> These are all afterthoughts.
Since the subject line includes S/370, 31 bits is not an after thought.
--
Dan Espen
|
|
|
|
| Re: IBM S/360 - 370 [message #396047 is a reply to message #396016] |
Mon, 22 June 2020 12:48 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, June 21, 2020 at 9:29:57 PM UTC-6, robin...@gmail.com wrote:
> On Monday, June 22, 2020 at 1:32:41 AM UTC+10, Quadibloc wrote:
>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>
>>> The base-displacement addressing model proved to be
>>> an impediment, tying up valuable general registers;
>>> instruction-relative addressing would have been far better.
>>
>> Base displacement addressing lets a program call a subroutine that might be
>> located at a far-away location in memory, such as, say, a resident library
>> routine. You can't do that with only program counter-relative addressing.
>
> A branch instruction can use the contents of a word as an address
> (as is done now, and as has been done since the first S/360).
> The word would be addressed with instruction-relative addressing.
Indirect addressing has been around before the first System/360, but it's a form
of addressing the System/360 itself eschewed.
John Savard
|
|
|
|
| Re: IBM S/360 - 370 [message #396048 is a reply to message #396043] |
Mon, 22 June 2020 13:21 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, June 23, 2020 at 1:44:08 AM UTC+10, Dan Espen wrote:
> r......@gmail.com writes:
>
>> On Monday, June 22, 2020 at 2:36:52 PM UTC+10, Dan Espen wrote:
>>> r......@gmail.com writes:
>>>
>>>> On Monday, June 22, 2020 at 1:32:41 AM UTC+10, Quadibloc wrote:
>>>> > On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>>> >
>>>> > > The base-displacement addressing model proved to be
>>>> > > an impediment, tying up valuable general registers;
>>>> > > instruction-relative addressing would have been far better.
>>>> >
>>>> > Base displacement addressing lets a program call a subroutine that might be
>>>> > located at a far-away location in memory, such as, say, a resident library
>>>> > routine. You can't do that with only program counter-relative addressing.
>>>>
>>>> A branch instruction can use the contents of a word as an address
>>>> (as is done now, and as has been done since the first S/360).
>>>> The word would be addressed with instruction-relative addressing.
>>>
>>> Sounds to me like you are describing S/360 JUMP instructions.
>>
>> No I'm not.
>> They are base-relative instructions, and suffer from the
>> the same range problems as all the other instructions
>> that use base-displacement addressing.
>>
>>> They have been part of the architecture for a long time now.
>>
>> Since c. 1966.
>>
>>> They do an interesting trick, the jump offset must be even so the
>>> displacement is shifted one bit before use.
>>
>> No they don't. The Bxx family (B, BH, BL etc) use base-displacement
>> addressing, and the displacement is never shifted.
>
> I suggest you download a current POP manual and read about Branch Relative
> instructions.
That's entirely irrelevant.
This discussion us about the original IBM S/360 + 370
(see Subject).
|
|
|
|
| Re: IBM S/360 - 370 [message #396049 is a reply to message #396047] |
Mon, 22 June 2020 13:29 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, June 23, 2020 at 2:48:45 AM UTC+10, Quadibloc wrote:
> On Sunday, June 21, 2020 at 9:29:57 PM UTC-6, robin...@gmail.com wrote:
>> On Monday, June 22, 2020 at 1:32:41 AM UTC+10, Quadibloc wrote:
>>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>>
>>>> The base-displacement addressing model proved to be
>>>> an impediment, tying up valuable general registers;
>>>> instruction-relative addressing would have been far better.
>>>
>>> Base displacement addressing lets a program call a subroutine that might be
>>> located at a far-away location in memory, such as, say, a resident library
>>> routine. You can't do that with only program counter-relative addressing.
>>
>> A branch instruction can use the contents of a word as an address
>> (as is done now, and as has been done since the first S/360).
>> The word would be addressed with instruction-relative addressing.
>
> Indirect addressing has been around before the first System/360, but it's a form
> of addressing the System/360 itself eschewed.
um ... call by address?
|
|
|
|
| Re: IBM S/360 - 370 [message #396050 is a reply to message #396049] |
Mon, 22 June 2020 13:41 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2020-06-22, robin.vowels@gmail.com <robin.vowels@gmail.com> wrote:
> On Tuesday, June 23, 2020 at 2:48:45 AM UTC+10, Quadibloc wrote:
>
>> On Sunday, June 21, 2020 at 9:29:57 PM UTC-6, robin...@gmail.com wrote:
>>
>>> On Monday, June 22, 2020 at 1:32:41 AM UTC+10, Quadibloc wrote:
>>>
>>>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>>>
>>>> > The base-displacement addressing model proved to be
>>>> > an impediment, tying up valuable general registers;
>>>> > instruction-relative addressing would have been far better.
>>>>
>>>> Base displacement addressing lets a program call a subroutine that
>>>> might be located at a far-away location in memory, such as, say,
>>>> a resident library routine. You can't do that with only program
>>>> counter-relative addressing.
>>>
>>> A branch instruction can use the contents of a word as an address
>>> (as is done now, and as has been done since the first S/360).
>>> The word would be addressed with instruction-relative addressing.
>>
>> Indirect addressing has been around before the first System/360,
>> but it's a form of addressing the System/360 itself eschewed.
>
> um ... call by address?
Could you give us an example, please? You're implying that this
is an addressing mode available to a single instruction, but the
only way I can see it being done is with two instructions:
L 15,CALLADDR
BALR 14,15
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
|
|
|
|
| Re: IBM S/360 - 370 [message #396051 is a reply to message #396013] |
Mon, 22 June 2020 14:32 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Sunday, June 21, 2020 at 11:21:19 AM UTC-6, J. Clarke wrote:
>> On Sun, 21 Jun 2020 08:32:39 -0700 (PDT), Quadibloc
>> <jsavard@ecn.ab.ca> wrote:
>>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>
>>>> The base-displacement addressing model proved to be
>>>> an impediment, tying up valuable general registers;
>>>> instruction-relative addressing would have been far better.
>
>>> Base displacement addressing lets a program call a subroutine that might be
>>> located at a far-away location in memory, such as, say, a resident library
>>> routine. You can't do that with only program counter-relative addressing.
>
>>> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
>
>> What leads you to believe that X86 does not have base-displacement
>> addressing?
>
> What led _him_ to believe that is presumably that it's called segment-offset
> addressing on the x86.
I believe that’s different. “MOV EAX,32[EBX]” would, I think, not be
considered segment-offset.
>
> Of course, though, the 370 was *better*, since you used numbered registers for
> bases, so you were free to use several of them for whatever purposes you wanted,
> where the use of the segment registers is limited on the x86 and you just have
> one spare one to use for extra purposes.
>
> John Savard
>
--
Pete
|
|
|
|
| Re: IBM S/360 - 370 [message #396052 is a reply to message #396014] |
Mon, 22 June 2020 14:32 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Jon Elson <elson@pico-systems.com> wrote:
>
> Also, the scheme of saving the subroutine return address in a register
> caused a LOT of program crashes and infinite loops. I find a stack call
> system a lot better.
Probably so. The lack of a hardware stack added a lot of overhead, with an
SVC to allocate a savearea at the start of almost every called subroutine.
--
Pete
|
|
|
|
| Re: IBM S/360 - 370 [message #396053 is a reply to message #396018] |
Mon, 22 June 2020 14:32 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
<robin.vowels@gmail.com> wrote:
> On Monday, June 22, 2020 at 11:53:42 AM UTC+10, Jon Elson wrote:
>> r.......@gmail.com wrote:
>>
>>> On Friday, July 25, 2014 at 6:52:05 AM UTC+10, Jon Elson wrote:
>>>
>>>> The 370 series was a practical architecture, although the performance
>>>> of some of the lower models seems like it must have been intentionally
>>>> crippled to not interfere with the /15x and /16x machine.
>>>
>>> What do you mean, "practical architecture"?
>>>
>>> While it has some exotic instructions (such as EDMK, TR, TRT etc),
>>> it lacked practical or useful instructions such as:
>>>
>>> Increment a binary integer
>
>> Acttually, I think you can use the load address instruction to do this.
>
> No.
> LA requires that the result be only 24 bits, and that the result be positive.
> Anything above that is truncated.
> And it does not set the condition code, so it's worthless for
> that purpose.
Certainly not worthless, because 24 bits is adequate for most counters,
etc. It’s used extensively for this.
--
Pete
|
|
|
|
| Re: IBM S/360 - 370 [message #396054 is a reply to message #396021] |
Mon, 22 June 2020 14:32 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> robin.vowels@gmail.com writes:
>
>> On Monday, June 22, 2020 at 2:17:29 AM UTC+10, John Levine wrote:
>>> In article <46debf5e......@googlegroups.com>,
>>> <r......@gmail.com> wrote:
>>>> On Friday, July 25, 2014 at 6:52:05 AM UTC+10, Jon Elson wrote:
>>>>
>>>> > The 370 series was a practical architecture, although the
>>>> > performance of some of the lower models seems like it must have
>>>> > been intentionally crippled to not interfere with the /15x and
>>>> > /16x machine.
>>>>
>>>> What do you mean, "practical architecture"?
>>>
>>> One that is still in use every day, while nearly every other 1960s
>>> architecture is dead?
>>>
>>>> While it has some exotic instructions (such as EDMK, TR, TRT etc),
>>>> it lacked practical or useful instructions such as:
>>>>
>>>> Increment a binary integer Increment a binary integer in storage;
>>>> generate a 32-bit binary constant using an immediate instruction;
>>>> increment a 32-bit binary number using an immediate instruction.
>>>
>>> If the integer was less than 24 bits you could use LA. Other than
>>> that they seem to agree with you since S/390 has load and add
>>> immediate with 16 bit values and relative branches. zSeries adds 32
>>> bit immediate versions of most RX instructions.
>>>
>>>> Such instructions existed on earlier machines ...
>>>>
>>>> The base-displacement addressing model proved to be an impediment,
>>>> tying up valuable general registers; instruction-relative addressing
>>>> would have been far better.
>>>
>>> Relative addressing is fine for branches but less so for data.
>>> zSeries added 20 bit displacements to most B+D instructions and a few
>>> relative addressed data instructions.
>>>
>>> As far as I can tell, there were two motivations for based addressing
>>> with 12 bit displacements which even in 1963 were pretty small. One
>>> was to have an instruction format that worked reasonably well both on
>>> small systems with 32K or 64K of memory and on large systems with a
>>> megabyte or more. That worked well.
>>
>> No it didn't.
>>
>>> They knew that programs would need several base registers, but with
>>> 16 registers there were enough.
>>
>> No there weren't. The XPL compiler has available only 3 registers for
>> general arithmetic; the remainder are taken up with base addressing
>> and other addressing, and there are still not enough.
>>
>>> The other was that they imagined that since all memory references
>>> were base-relative, they could move programs and data around by
>>> changing the base registsters and didn't need relocation hardware.
>>
>> Did they ever do that?
>
> It's sort of basic that a S/360 program can load at any address.
>
> Reentrant programs can be shared. The LE compilers can make reentrant
> code.
>
Reentrant, but usually once they’re loaded they don’t move. TSS did a lot
of tricks to allow a single copy of a program to appear at different
addresses in different address spaces.
--
Pete
|
|
|
|
| Re: IBM S/360 - 370 [message #396055 is a reply to message #396043] |
Mon, 22 June 2020 14:32 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> robin.vowels@gmail.com writes:
>
>> On Monday, June 22, 2020 at 2:36:52 PM UTC+10, Dan Espen wrote:
>>> r......@gmail.com writes:
>>>
>>>> On Monday, June 22, 2020 at 1:32:41 AM UTC+10, Quadibloc wrote:
>>>> > On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>>> >
>>>> >> The base-displacement addressing model proved to be
>>>> >> an impediment, tying up valuable general registers;
>>>> >> instruction-relative addressing would have been far better.
>>>> >
>>>> > Base displacement addressing lets a program call a subroutine that might be
>>>> > located at a far-away location in memory, such as, say, a resident library
>>>> > routine. You can't do that with only program counter-relative addressing.
>>>>
>>>> A branch instruction can use the contents of a word as an address
>>>> (as is done now, and as has been done since the first S/360).
>>>> The word would be addressed with instruction-relative addressing.
>>>
>>> Sounds to me like you are describing S/360 JUMP instructions.
>>
>> No I'm not.
>> They are base-relative instructions, and suffer from the
>> the same range problems as all the other instructions
>> that use base-displacement addressing.
>>
>>> They have been part of the architecture for a long time now.
>>
>> Since c. 1966.
>>
>>> They do an interesting trick, the jump offset must be even so the
>>> displacement is shifted one bit before use.
>>
>> No they don't. The Bxx family (B, BH, BL etc) use base-displacement
>> addressing, and the displacement is never shifted.
>
> I suggest you download a current POP manual and read about Branch Relative
> instructions.
This discussion is anachronistic. We’re comparing original and current
models of S/360 (now System/z) and x86 (x86-64) We should at least be
comparing relatively contemporaneous systems. Maybe original S/360
compared to pentium, although there’s probably a 20 year time difference
here.
>
> Here's one:
>
> Branch relative on Condition Long:
>
> The contents of the RI2 field are a signed binary inte-
> ger specifying the number of halfwords that is added
> to the address of the instruction to generate the
> branch address.
>
> (The RI2 field is bits 16-47.)
>
--
Pete
|
|
|
|
| Re: IBM S/360 - 370 [message #396056 is a reply to message #396049] |
Mon, 22 June 2020 14:32 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
<robin.vowels@gmail.com> wrote:
> On Tuesday, June 23, 2020 at 2:48:45 AM UTC+10, Quadibloc wrote:
>> On Sunday, June 21, 2020 at 9:29:57 PM UTC-6, robin...@gmail.com wrote:
>>> On Monday, June 22, 2020 at 1:32:41 AM UTC+10, Quadibloc wrote:
>>>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>>>
>>>> > The base-displacement addressing model proved to be
>>>> > an impediment, tying up valuable general registers;
>>>> > instruction-relative addressing would have been far better.
>>>>
>>>> Base displacement addressing lets a program call a subroutine that might be
>>>> located at a far-away location in memory, such as, say, a resident library
>>>> routine. You can't do that with only program counter-relative addressing.
>>>
>>> A branch instruction can use the contents of a word as an address
>>> (as is done now, and as has been done since the first S/360).
>>> The word would be addressed with instruction-relative addressing.
>>
>> Indirect addressing has been around before the first System/360, but it's a form
>> of addressing the System/360 itself eschewed.
>
> um ... call by address?
>
That’s direct.
--
Pete
|
|
|
|
| Re: IBM S/360 - 370 [message #396059 is a reply to message #396052] |
Mon, 22 June 2020 18:14 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Jon Elson <elson@pico-systems.com> wrote:
>>
>> Also, the scheme of saving the subroutine return address in a register
>> caused a LOT of program crashes and infinite loops. I find a stack call
>> system a lot better.
>
> Probably so. The lack of a hardware stack added a lot of overhead, with an
> SVC to allocate a savearea at the start of almost every called subroutine.
z/Architecture has PC Program Call, PR Program Return.
One instruction, but it has to do the same register save.
My guess is it won't be any faster.
--
Dan Espen
|
|
|
|
| Re: IBM S/360 - 370 [message #396060 is a reply to message #396055] |
Mon, 22 June 2020 18:27 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Dan Espen <dan1espen@gmail.com> wrote:
>> robin.vowels@gmail.com writes:
>>
>>> On Monday, June 22, 2020 at 2:36:52 PM UTC+10, Dan Espen wrote:
>>>> r......@gmail.com writes:
>>>>
>>>> > On Monday, June 22, 2020 at 1:32:41 AM UTC+10, Quadibloc wrote:
>>>> >> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>>> >>
>>>> >>> The base-displacement addressing model proved to be
>>>> >>> an impediment, tying up valuable general registers;
>>>> >>> instruction-relative addressing would have been far better.
>>>> >>
>>>> >> Base displacement addressing lets a program call a subroutine that might be
>>>> >> located at a far-away location in memory, such as, say, a resident library
>>>> >> routine. You can't do that with only program counter-relative addressing.
>>>> >
>>>> > A branch instruction can use the contents of a word as an address
>>>> > (as is done now, and as has been done since the first S/360).
>>>> > The word would be addressed with instruction-relative addressing.
>>>>
>>>> Sounds to me like you are describing S/360 JUMP instructions.
>>>
>>> No I'm not.
>>> They are base-relative instructions, and suffer from the
>>> the same range problems as all the other instructions
>>> that use base-displacement addressing.
>>>
>>>> They have been part of the architecture for a long time now.
>>>
>>> Since c. 1966.
>>>
>>>> They do an interesting trick, the jump offset must be even so the
>>>> displacement is shifted one bit before use.
>>>
>>> No they don't. The Bxx family (B, BH, BL etc) use base-displacement
>>> addressing, and the displacement is never shifted.
>>
>> I suggest you download a current POP manual and read about Branch Relative
>> instructions.
>
> This discussion is anachronistic. We’re comparing original and current
> models of S/360 (now System/z) and x86 (x86-64) We should at least be
> comparing relatively contemporaneous systems. Maybe original S/360
> compared to pentium, although there’s probably a 20 year time difference
> here.
Branch Relative is pretty old.
It certainly predates x86-64.
My point was IBM figured out that their older architecture was lacking.
The evidence is the addition of the instructions.
--
Dan Espen
|
|
|
|
| Re: IBM S/360 - 370 [message #396061 is a reply to message #396056] |
Mon, 22 June 2020 18:36 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> <robin.vowels@gmail.com> wrote:
>> On Tuesday, June 23, 2020 at 2:48:45 AM UTC+10, Quadibloc wrote:
>>> On Sunday, June 21, 2020 at 9:29:57 PM UTC-6, robin...@gmail.com wrote:
>>>> On Monday, June 22, 2020 at 1:32:41 AM UTC+10, Quadibloc wrote:
>>>> > On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>>> >
>>>> >> The base-displacement addressing model proved to be an
>>>> >> impediment, tying up valuable general registers;
>>>> >> instruction-relative addressing would have been far better.
>>>> >
>>>> > Base displacement addressing lets a program call a subroutine that
>>>> > might be located at a far-away location in memory, such as, say, a
>>>> > resident library routine. You can't do that with only program
>>>> > counter-relative addressing.
>>>>
>>>> A branch instruction can use the contents of a word as an address
>>>> (as is done now, and as has been done since the first S/360). The
>>>> word would be addressed with instruction-relative addressing.
>>>
>>> Indirect addressing has been around before the first System/360, but
>>> it's a form of addressing the System/360 itself eschewed.
>>
>> um ... call by address?
>
> That’s direct.
S/360 does indirect addressing by loading pointers into registers then
using that register to load another address. Lots and lots of chain
following. I don't think anyone wants IBM to try to do that in
hardware.
--
Dan Espen
|
|
|
|
| Re: IBM S/360 - 370 [message #396063 is a reply to message #396052] |
Mon, 22 June 2020 19:23 |
|
|
Originally posted by: antispam
Peter Flass <peter_flass@yahoo.com> wrote:
> Jon Elson <elson@pico-systems.com> wrote:
>>
>> Also, the scheme of saving the subroutine return address in a register
>> caused a LOT of program crashes and infinite loops. I find a stack call
>> system a lot better.
>
> Probably so. The lack of a hardware stack added a lot of overhead, with an
> SVC to allocate a savearea at the start of almost every called subroutine.
That was not hardware problem, but inefficient software convention.
Consider alterantive convention:
- down going stack with stack pointer in R15
- R14 pointing to entry point, R13 containing return address
- R0 to R5 volatile (caller saved), used for arguments and
return values
- R13 and R14 can be changed by callee at will
- other general registers preserved by caller
Then general prologue looks like:
S R15,val allocate stack frame
STM R6,R13,0(R15) save registers
LR R12,R14 establish addressability via R12
that is 14 bytes code (including 4 bytes for constant in memory), way
better than original convention and not bad by modern standards.
Return is
L R13,28(R15)
LA R15,val(R15) deallocate stack frame
BCR 15,R13 return
10 bytes, again not bad.
In general call may have to save some registers so in worse case
this may require more instructions in body than original convention.
However, with such convention there are opportunities to optimize.
Simple leaf functions may get away without any prologue and with
one instruction return (assuming that they can do all work in
volatile registers). Many functions will do all body work within
available registers, without any extra saves around calls.
Local variables can be on stack, reachable with positive offset
from stack pointers so simple L or ST will load/save them.
Of course, this works well up to 4kB code and 4kB local variables.
But problems for bigger routines are due to too limited displacement
and have nothing to do with keeping return address in register
(which IMO is the best calling convention).
--
Waldek Hebisch
|
|
|
|
| Re: IBM S/360 - 370 [message #396064 is a reply to message #396063] |
Mon, 22 June 2020 20:33 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
antispam@math.uni.wroc.pl writes:
> Peter Flass <peter_flass@yahoo.com> wrote:
>> Jon Elson <elson@pico-systems.com> wrote:
>>>
>>> Also, the scheme of saving the subroutine return address in a register
>>> caused a LOT of program crashes and infinite loops. I find a stack call
>>> system a lot better.
>>
>> Probably so. The lack of a hardware stack added a lot of overhead, with an
>> SVC to allocate a savearea at the start of almost every called subroutine.
>
> That was not hardware problem, but inefficient software convention.
> Consider alterantive convention:
> - down going stack with stack pointer in R15
> - R14 pointing to entry point, R13 containing return address
> - R0 to R5 volatile (caller saved), used for arguments and
> return values
> - R13 and R14 can be changed by callee at will
> - other general registers preserved by caller
>
> Then general prologue looks like:
>
> S R15,val allocate stack frame
> STM R6,R13,0(R15) save registers
> LR R12,R14 establish addressability via R12
>
> that is 14 bytes code (including 4 bytes for constant in memory), way
> better than original convention and not bad by modern standards.
An LE prologue does stack pointer moving.
It has to check the pointer can be decremented
with the remaining space.
It can't just assume an infinite stack.
> Return is
>
> L R13,28(R15)
> LA R15,val(R15) deallocate stack frame
> BCR 15,R13 return
>
> 10 bytes, again not bad.
>
> In general call may have to save some registers so in worse case
> this may require more instructions in body than original convention.
> However, with such convention there are opportunities to optimize.
> Simple leaf functions may get away without any prologue and with
> one instruction return (assuming that they can do all work in
> volatile registers). Many functions will do all body work within
> available registers, without any extra saves around calls.
> Local variables can be on stack, reachable with positive offset
> from stack pointers so simple L or ST will load/save them.
>
> Of course, this works well up to 4kB code and 4kB local variables.
> But problems for bigger routines are due to too limited displacement
> and have nothing to do with keeping return address in register
> (which IMO is the best calling convention).
I once wrote a set of HLASM entry and exit macros.
One of the keyword parameters was REGS=(FROM,TO)
which represented the only registers to be saved.
That made it a good idea to use R1 through the lowest number register
needed. In most subroutines I managed to use 4 or less registers, so (R1,R4).
Quite a difference compared to saving 14,12.
--
Dan Espen
|
|
|
|
| Re: IBM S/360 - 370 [message #396066 is a reply to message #396063] |
Mon, 22 June 2020 21:16 |
|
|
Originally posted by: antispam
antispam@math.uni.wroc.pl wrote:
> Peter Flass <peter_flass@yahoo.com> wrote:
>> Jon Elson <elson@pico-systems.com> wrote:
>>>
>>> Also, the scheme of saving the subroutine return address in a register
>>> caused a LOT of program crashes and infinite loops. I find a stack call
>>> system a lot better.
>>
>> Probably so. The lack of a hardware stack added a lot of overhead, with an
>> SVC to allocate a savearea at the start of almost every called subroutine.
Correcting silly error.
>
> That was not hardware problem, but inefficient software convention.
> Consider alterantive convention:
> - down going stack with stack pointer in R15
> - R14 pointing to entry point, R13 containing return address
> - R0 to R5 volatile (caller saved), used for arguments and
> return values
> - R13 and R14 can be changed by callee at will
> - other general registers preserved by caller
>
> Then general prologue looks like:
>
> S R15,val allocate stack frame
> STM R6,R13,0(R15) save registers
> LR R12,R14 establish addressability via R12
>
> that is 14 bytes code (including 4 bytes for constant in memory), way
> better than original convention and not bad by modern standards.
>
> Return is
>
> L R13,28(R15)
LM R6,R13,0(R15) restore registers
> LA R15,val(R15) deallocate stack frame
> BCR 15,R13 return
>
> 10 bytes, again not bad.
Of course one need also restore registers, still not bad.
>
> In general call may have to save some registers so in worse case
> this may require more instructions in body than original convention.
> However, with such convention there are opportunities to optimize.
> Simple leaf functions may get away without any prologue and with
> one instruction return (assuming that they can do all work in
> volatile registers). Many functions will do all body work within
> available registers, without any extra saves around calls.
> Local variables can be on stack, reachable with positive offset
> from stack pointers so simple L or ST will load/save them.
>
> Of course, this works well up to 4kB code and 4kB local variables.
> But problems for bigger routines are due to too limited displacement
> and have nothing to do with keeping return address in register
> (which IMO is the best calling convention).
>
--
Waldek Hebisch
|
|
|
|
| Re: IBM S/360 - 370 [message #396067 is a reply to message #396064] |
Mon, 22 June 2020 21:43 |
|
|
Originally posted by: antispam
Dan Espen <dan1espen@gmail.com> wrote:
> antispam@math.uni.wroc.pl writes:
>
>> Peter Flass <peter_flass@yahoo.com> wrote:
>>> Jon Elson <elson@pico-systems.com> wrote:
>>>>
>>>> Also, the scheme of saving the subroutine return address in a register
>>>> caused a LOT of program crashes and infinite loops. I find a stack call
>>>> system a lot better.
>>>
>>> Probably so. The lack of a hardware stack added a lot of overhead, with an
>>> SVC to allocate a savearea at the start of almost every called subroutine.
>>
>> That was not hardware problem, but inefficient software convention.
>> Consider alterantive convention:
>> - down going stack with stack pointer in R15
>> - R14 pointing to entry point, R13 containing return address
>> - R0 to R5 volatile (caller saved), used for arguments and
>> return values
>> - R13 and R14 can be changed by callee at will
>> - other general registers preserved by caller
>>
>> Then general prologue looks like:
>>
>> S R15,val allocate stack frame
>> STM R6,R13,0(R15) save registers
>> LR R12,R14 establish addressability via R12
>>
>> that is 14 bytes code (including 4 bytes for constant in memory), way
>> better than original convention and not bad by modern standards.
>
> An LE prologue does stack pointer moving.
> It has to check the pointer can be decremented
> with the remaining space.
>
> It can't just assume an infinite stack.
370 has virtual memory. Standard stack-checking trick is to
put non-present guard page below allocated stack area. Then
stack overflow will lead to reference to guard page.
Operating system will detect this. Helpful operating system
will transfer control to handler on alternative stack.
Note that this prologue always performs store to new top.
Due to limited displacement 370 can not skip over page so this
will immediately catch stack overflow -- basically as good as
explicit check, but without extra overhead. On architecture
with longer displacement one have to either use more guard
pages or add stores to intermedate positions to force early
fault.
On 360 without virtual memory this does not work. OTOH
in 360 era recursive routines were rare and without
recursion one can easily staticaly compute maximal possible
stack use and simply allocate what is needed.
>
>> Return is
>>
>> L R13,28(R15)
>> LA R15,val(R15) deallocate stack frame
>> BCR 15,R13 return
>>
>> 10 bytes, again not bad.
>>
>> In general call may have to save some registers so in worse case
>> this may require more instructions in body than original convention.
>> However, with such convention there are opportunities to optimize.
>> Simple leaf functions may get away without any prologue and with
>> one instruction return (assuming that they can do all work in
>> volatile registers). Many functions will do all body work within
>> available registers, without any extra saves around calls.
>> Local variables can be on stack, reachable with positive offset
>> from stack pointers so simple L or ST will load/save them.
>>
>> Of course, this works well up to 4kB code and 4kB local variables.
>> But problems for bigger routines are due to too limited displacement
>> and have nothing to do with keeping return address in register
>> (which IMO is the best calling convention).
>
> I once wrote a set of HLASM entry and exit macros.
> One of the keyword parameters was REGS=(FROM,TO)
> which represented the only registers to be saved.
>
> That made it a good idea to use R1 through the lowest number register
> needed. In most subroutines I managed to use 4 or less registers, so (R1,R4).
> Quite a difference compared to saving 14,12.
Yes, you can save time that way. Still, register calling convention
almost surely would give significant additional saving. Of course,
with calling convention different from IBM you would need extra
compatibility layer to call IBM routines and standard tools like
debuggers would have problems. So I understand why people
are not doing this, compatiblity wins over efficiency gain...
(IIUC your approach used standard save area, so was compatible).
--
Waldek Hebisch
|
|
|
|
| Re: IBM S/360 - 370 [message #396068 is a reply to message #396059] |
Mon, 22 June 2020 21:52 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>
>> Jon Elson <elson@pico-systems.com> wrote:
>>>
>>> Also, the scheme of saving the subroutine return address in a register
>>> caused a LOT of program crashes and infinite loops. I find a stack call
>>> system a lot better.
>>
>> Probably so. The lack of a hardware stack added a lot of overhead, with an
>> SVC to allocate a savearea at the start of almost every called subroutine.
>
> z/Architecture has PC Program Call, PR Program Return.
> One instruction, but it has to do the same register save.
> My guess is it won't be any faster.
>
Gotbto be faster than having to do an SVC.
--
Pete
|
|
|
|
| Re: IBM S/360 - 370 [message #396069 is a reply to message #396060] |
Mon, 22 June 2020 21:52 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>
>> Dan Espen <dan1espen@gmail.com> wrote:
>>> robin.vowels@gmail.com writes:
>>>
>>>> On Monday, June 22, 2020 at 2:36:52 PM UTC+10, Dan Espen wrote:
>>>> > r......@gmail.com writes:
>>>> >
>>>> >> On Monday, June 22, 2020 at 1:32:41 AM UTC+10, Quadibloc wrote:
>>>> >>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>>> >>>
>>>> >>>> The base-displacement addressing model proved to be
>>>> >>>> an impediment, tying up valuable general registers;
>>>> >>>> instruction-relative addressing would have been far better.
>>>> >>>
>>>> >>> Base displacement addressing lets a program call a subroutine that might be
>>>> >>> located at a far-away location in memory, such as, say, a resident library
>>>> >>> routine. You can't do that with only program counter-relative addressing.
>>>> >>
>>>> >> A branch instruction can use the contents of a word as an address
>>>> >> (as is done now, and as has been done since the first S/360).
>>>> >> The word would be addressed with instruction-relative addressing.
>>>> >
>>>> > Sounds to me like you are describing S/360 JUMP instructions.
>>>>
>>>> No I'm not.
>>>> They are base-relative instructions, and suffer from the
>>>> the same range problems as all the other instructions
>>>> that use base-displacement addressing.
>>>>
>>>> > They have been part of the architecture for a long time now.
>>>>
>>>> Since c. 1966.
>>>>
>>>> > They do an interesting trick, the jump offset must be even so the
>>>> > displacement is shifted one bit before use.
>>>>
>>>> No they don't. The Bxx family (B, BH, BL etc) use base-displacement
>>>> addressing, and the displacement is never shifted.
>>>
>>> I suggest you download a current POP manual and read about Branch Relative
>>> instructions.
>>
>> This discussion is anachronistic. We’re comparing original and current
>> models of S/360 (now System/z) and x86 (x86-64) We should at least be
>> comparing relatively contemporaneous systems. Maybe original S/360
>> compared to pentium, although there’s probably a 20 year time difference
>> here.
>
> Branch Relative is pretty old.
> It certainly predates x86-64.
>
> My point was IBM figured out that their older architecture was lacking.
> The evidence is the addition of the instructions.
>
Branch Relative, at least, was added to support gcc in order to port Linux.
I’m not that up on instructions newer than S/370, so I can’t speak to any
others.
--
Pete
|
|
|
|
| Re: IBM S/360 - 370 [message #396073 is a reply to message #396068] |
Mon, 22 June 2020 22:59 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Dan Espen <dan1espen@gmail.com> wrote:
>> Peter Flass <peter_flass@yahoo.com> writes:
>>
>>> Jon Elson <elson@pico-systems.com> wrote:
>>>>
>>>> Also, the scheme of saving the subroutine return address in a register
>>>> caused a LOT of program crashes and infinite loops. I find a stack call
>>>> system a lot better.
>>>
>>> Probably so. The lack of a hardware stack added a lot of overhead, with an
>>> SVC to allocate a savearea at the start of almost every called subroutine.
>>
>> z/Architecture has PC Program Call, PR Program Return.
>> One instruction, but it has to do the same register save.
>> My guess is it won't be any faster.
>
> Gotbto be faster than having to do an SVC.
Absolutely.
I guess you mean a getmain svc.
Not sure I've seen too many cases of doing a stack getmain
for a subroutine call.
--
Dan Espen
|
|
|
|
| Re: IBM S/360 - 370 [message #396075 is a reply to message #396029] |
Tue, 23 June 2020 02:22 |
Bob Martin
Messages: 157
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
On 22 Jun 2020 at 08:13:28, robin.vowels@gmail.com wrote:
> On Monday, June 22, 2020 at 3:43:50 PM UTC+10, Bob Martin wrote:
>> On 21 Jun 2020 at 15:32:39, Quadibloc <j......@ecn.ab.ca> wrote:
>>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, r.......@gmail.com wrote:
>>>
>>>> The base-displacement addressing model proved to be
>>>> an impediment, tying up valuable general registers;
>>>> instruction-relative addressing would have been far better.
>>>
>>> Base displacement addressing lets a program call a subroutine that might be
>>> located at a far-away location in memory, such as, say, a resident library
>>> routine. You can't do that with only program counter-relative addressing.
>>>
>>> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
>>
>> +1
>>
>> OS/360 had non-blocking I/O from the off in 1964
>
> OS/360 and the S/360 were not then in existence.
What are you talking about?
S/360 was announced in April 1964. I was there.
>
>> (I was at the announcement).
>> When did X86 get it?
>
> Non-blocking I/O existed from at least 1958, if not before.
|
|
|
|
| Re: IBM S/360 - 370 [message #396081 is a reply to message #396073] |
Tue, 23 June 2020 09:41 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>
>> Dan Espen <dan1espen@gmail.com> wrote:
>>> Peter Flass <peter_flass@yahoo.com> writes:
>>>
>>>> Jon Elson <elson@pico-systems.com> wrote:
>>>> >
>>>> > Also, the scheme of saving the subroutine return address in a register
>>>> > caused a LOT of program crashes and infinite loops. I find a stack call
>>>> > system a lot better.
>>>>
>>>> Probably so. The lack of a hardware stack added a lot of overhead, with an
>>>> SVC to allocate a savearea at the start of almost every called subroutine.
>>>
>>> z/Architecture has PC Program Call, PR Program Return.
>>> One instruction, but it has to do the same register save.
>>> My guess is it won't be any faster.
>>
>> Gotbto be faster than having to do an SVC.
>
> Absolutely.
>
> I guess you mean a getmain svc.
> Not sure I've seen too many cases of doing a stack getmain
> for a subroutine call.
>
That’s the recommended method for reerentrant code. I’ve never done
anything else, except for internal subroutines where I would use a tailored
linkage convention.
--
Pete
|
|
|
|
| Re: IBM S/360 - 370 [message #396082 is a reply to message #396081] |
Tue, 23 June 2020 10:08 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Dan Espen <dan1espen@gmail.com> wrote:
>> Peter Flass <peter_flass@yahoo.com> writes:
>>
>>> Dan Espen <dan1espen@gmail.com> wrote:
>>>> Peter Flass <peter_flass@yahoo.com> writes:
>>>>
>>>> > Jon Elson <elson@pico-systems.com> wrote:
>>>> >>
>>>> >> Also, the scheme of saving the subroutine return address in a register
>>>> >> caused a LOT of program crashes and infinite loops. I find a stack call
>>>> >> system a lot better.
>>>> >
>>>> > Probably so. The lack of a hardware stack added a lot of overhead, with an
>>>> > SVC to allocate a savearea at the start of almost every called subroutine.
>>>>
>>>> z/Architecture has PC Program Call, PR Program Return.
>>>> One instruction, but it has to do the same register save.
>>>> My guess is it won't be any faster.
>>>
>>> Gotbto be faster than having to do an SVC.
>>
>> Absolutely.
>>
>> I guess you mean a getmain svc.
>> Not sure I've seen too many cases of doing a stack getmain
>> for a subroutine call.
>
> That’s the recommended method for reerentrant code. I’ve never done
> anything else, except for internal subroutines where I would use a tailored
> linkage convention.
In my experience, the main does a large getmain the subroutines
use pieces of the storage. That's what LE does too.
--
Dan Espen
|
|
|
|
| Re: IBM S/360 - 370 [message #396086 is a reply to message #396023] |
Tue, 23 June 2020 12:23 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
robin.vowels@gmail.com wrote:
> On Monday, June 22, 2020 at 2:36:52 PM UTC+10, Dan Espen wrote:
>> r......@gmail.com writes:
>> Sounds to me like you are describing S/360 JUMP instructions.
>
> No I'm not.
> They are base-relative instructions, and suffer from the
> the same range problems as all the other instructions
> that use base-displacement addressing.
>
In any RX instruction, you can specify a base register of zero, and instead
of adding the contents of register zero, it is NOT added to the index
register plus offset. This allows you to use absolute addressing for a
branch or subroutine call (BALR). This is required when you call a shared
routine not in your partition.
(In any other RX instruction, you can do the same with a base reg
specification of zero, to use a stored absolute address to access some
data.)
Jon
|
|
|
|
| Re: IBM S/360 - 370 [message #396091 is a reply to message #396075] |
Tue, 23 June 2020 15:48 |
Rich Alderson
Messages: 489
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
Bob Martin <bob.martin@excite.com> writes:
> On 22 Jun 2020 at 08:13:28, robin.vowels@gmail.com wrote:
>> On Monday, June 22, 2020 at 3:43:50 PM UTC+10, Bob Martin wrote:
>>> On 21 Jun 2020 at 15:32:39, Quadibloc <j......@ecn.ab.ca> wrote:
>>>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, r.......@gmail.com wrote:
>>>> > The base-displacement addressing model proved to be an impediment, tying
>>>> > up valuable general registers; instruction-relative addressing would have
>>>> > been far better.
>>>> Base displacement addressing lets a program call a subroutine that might
>>>> be located at a far-away location in memory, such as, say, a resident
>>>> library routine. You can't do that with only program counter-relative
>>>> addressing.
>>>> The 370 architecture is head and shoulders above the dog's breakfast that
>>>> is x86.
>>> +1
>>> OS/360 had non-blocking I/O from the off in 1964
>> OS/360 and the S/360 were not then in existence.
> What are you talking about? S/360 was announced in April 1964. I was there.
The System/360 family was *announced* in April 1964 (three weeks after the DEC
PDP-6, as it happens), but first customer ship was October 1965. (First ship
on the PDP-6 was June 1964.)
So in one sense, the System/360 did not exist yet. OS/360 really did take a
long time to appear, with smaller operating systems (BOS/TOS/DOS) coming out
first to take up the slack.
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
|
|
|
|
| Re: IBM S/360 - 370 [message #396094 is a reply to message #396086] |
Tue, 23 June 2020 18:04 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <DNSdnXJCBI0WsW_DnZ2dnUU7-ROdnZ2d@giganews.com>,
Jon Elson <elson@pico-systems.com> wrote:
> robin.vowels@gmail.com wrote:
>
>> On Monday, June 22, 2020 at 2:36:52 PM UTC+10, Dan Espen wrote:
>>> r......@gmail.com writes:
>
>>> Sounds to me like you are describing S/360 JUMP instructions.
The S/360 has no "jump" instructions. They're called branches and
the relative ones were added for S/390
> In any RX instruction, you can specify a base register of zero, and instead
> of adding the contents of register zero, it is NOT added to the index
> register plus offset. This allows you to use absolute addressing for a
> branch or subroutine call (BALR). This is required when you call a shared
> routine not in your partition.
>
> (In any other RX instruction, you can do the same with a base reg
> specification of zero, to use a stored absolute address to access some
> data.)
i'm sorry but that's beyond wrong. RX instructions had a 12 bit offset
and two registers, each of which were added to the address if they
weren't R0. The difference between the base and index registers was
just a convention; they were handled the same.
Direct addressing could only address the lowest 4K of memory. It was
only useful for the first few instructions in an interrupt handler to
stash the registers and establish addressing for the rest of the
handler. As a special case LA, which put the computed address in a
register, could load an immediate 12 bit value into a register which
was often handy.
BR and BALR (and the later BASR) took the target address from a
register. The register was often loaded from memory with a preceding
RX load, but could be computed any way you want.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: IBM S/360 - 370 [message #396095 is a reply to message #396037] |
Tue, 23 June 2020 18:12 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <Sm3IG.21460$zX4.10037@fx41.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
>
> Only if you compare it with the 8088. A modern intel processor is as
> capable as any modern z-series processor. A flat 64-bit address space is
> much easier to use efficiently when compared to any segmented architecture.
In terms of instruction set I would generally agree. But for
industrial strength I/O, the zSeries is still way stronger.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: IBM S/360 - 370 [message #396096 is a reply to message #396017] |
Tue, 23 June 2020 18:16 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <a8fa4f4b-8ba6-42cb-896b-bc0ca97cd370o@googlegroups.com>,
<robin.vowels@gmail.com> wrote:
>> They knew that programs would need
>> several base registers, but with 16 registers there were enough.
>
> No there weren't. The XPL compiler has available only 3 registers
> for general arithmetic; the remainder are taken up with base addressing
> and other addressing, and there are still not enough.
That says more about the XPL compiler than the machine architecture.
Fortran H and X did all sorts of clever stuff with register temporaries.
>> The other was that they imagined that since all memory references were
>> base-relative, they could move programs and data around by changing
>> the base registsters and didn't need relocation hardware.
>
> Did they ever do that?
Um, did you read my next paragraph?
>> That was
>> wrong, because programs store pointers in memory, and you don't
>> generally know which which are the base registers. I believe that
>> APL\360 had very disciplined address management so it could move
>> users' data blocks around, but the code didn't move.
>
> Other systems used a program base register, and programs
> could be moved around, if required, without the user knowing
> anything about it.
Sure, the PDP-6 and PDP-10 did that. It was a mistake for S/360 not to
have addresss relocation which they fixed in the S/370 with the
virtual memory hardware.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: IBM S/360 - 370 addressing [message #396097 is a reply to message #396044] |
Tue, 23 June 2020 18:22 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <rcqjnu$u8v$2@dont-email.me>,
Dan Espen <dan1espen@gmail.com> wrote:
>>>> > The other was that they imagined that since all memory references
>>>> > were base-relative, they could move programs and data around by
>>>> > changing the base registsters and didn't need relocation hardware.
>>>>
>>>> Did they ever do that?
>>>
>>> It's sort of basic that a S/360 program can load at any address.
>>
>> Only if it uses Base-displacement addressing.
>> But programs cannot be shifted around in memory while the program
>> is being executed.
>
> True, but they don't need to be shifted around in order to be used
> by another address space at a different virtual address.
Only with considerable effort. TSS/360 could share code pages in
different jobs at different addresses but each routine had a sharable
position independent pure code CSECT and a non-sharable data PSECT.
The calling sequence was quite slow since the caller had to first put
a pointer to the called routine's PSECT at the end of the save area,
then do a call, then the called routine had to fetch that pointer so
it could address its own data. Dunno why they didn't put it in a
register but my guess was to make it more like the regular 360 calling
sequence and not have another reserved register across calls.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: IBM S/360 - 370 calling sequence [message #396098 is a reply to message #396052] |
Tue, 23 June 2020 18:28 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <1138497350.614542287.538088.peter_flass-yahoo.com@news.eternal-september.org>,
Peter Flass <peter_flass@yahoo.com> wrote:
> Jon Elson <elson@pico-systems.com> wrote:
>>
>> Also, the scheme of saving the subroutine return address in a register
>> caused a LOT of program crashes and infinite loops. I find a stack call
>> system a lot better.
>
> Probably so. The lack of a hardware stack added a lot of overhead, with an
> SVC to allocate a savearea at the start of almost every called subroutine.
I only saw that in the little used Algol F compiler.
You don't need push and pop instructions to implement a reasonable
stack so long as you have registers to point to the stack, which the
360 did.. The PL/I calling sequence allocated a chunk of memory and
put as many call frames as would fit in the chunk, then when the chunk
was full allocated another chunk and chained them together. It wasn't
super fast but it certainly didn't do a GETMAIN on every call.
FORTRAN and COBOL allocated storage including save areas statically,
didn't allow recursive calls, and didn't need a stack.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: IBM S/360 - 370 [message #396099 is a reply to message #396096] |
Tue, 23 June 2020 18:56 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> wrote:
> In article <a8fa4f4b-8ba6-42cb-896b-bc0ca97cd370o@googlegroups.com>,
> <robin.vowels@gmail.com> wrote:
>>> They knew that programs would need
>>> several base registers, but with 16 registers there were enough.
>>
>> No there weren't. The XPL compiler has available only 3 registers
>> for general arithmetic; the remainder are taken up with base addressing
>> and other addressing, and there are still not enough.
>
> That says more about the XPL compiler than the machine architecture.
> Fortran H and X did all sorts of clever stuff with register temporaries.
>
>>> The other was that they imagined that since all memory references were
>>> base-relative, they could move programs and data around by changing
>>> the base registsters and didn't need relocation hardware.
>>
>> Did they ever do that?
>
> Um, did you read my next paragraph?
>
>>> That was
>>> wrong, because programs store pointers in memory, and you don't
>>> generally know which which are the base registers. I believe that
>>> APL\360 had very disciplined address management so it could move
>>> users' data blocks around, but the code didn't move.
>>
>> Other systems used a program base register, and programs
>> could be moved around, if required, without the user knowing
>> anything about it.
>
> Sure, the PDP-6 and PDP-10 did that. It was a mistake for S/360 not to
> have addresss relocation which they fixed in the S/370 with the
> virtual memory hardware.
>
Machines of a slightly earlier vintage from other manufacturers had “base
and bounds” registers to at least allow programs and data to be relocated
as a block. Univac 110xx had i bank and d bank for separate program and
data. SDS 940 had several segment registers.
--
Pete
|
|
|
|
| Re: IBM S/360 - 370 and big offsets [message #396103 is a reply to message #396035] |
Wed, 24 June 2020 00:01 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <rcqao5$229$1@z-news.wcss.wroc.pl>,
<antispam@math.uni.wroc.pl> wrote:
> BTW. Apparently vendors love to repeat all mistakes. Most
> current architectures are 64-bit capable, but I know of no
> widely used architecture with 64-bit displacement for loads/stores
> (and the same for relative jumps). Such displacements would be
> used very rarely, but lack of them means that compiler either
> must contain unpleasent extra logic or bomb on large modules.
Honestly, if the compiler or linker fails when a single module is
bigger than 4 gigabytes, I can live with it.
I'm pretty sure I can live with 32-bit displacements for all of my
data references, too, since the idea of a data structure with fields
at fixed offsets greater than 4G apart is pretty unpleasant, too. A
giant array or table the total size of which is bigger than 4GB is
plausible, but you handle that with a register pointer stepping
through the table with the displacements used to get the individual
fields from each table entry.
Programs these days are assembled from a main program which is
typically just a stub to get going, and a bunch of shared libraries
that do the work. Calls from one library to another invariably use a
pointer table where on a 64 bit machine, the pointers are 64 bits.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: IBM S/360 - 370 [message #396104 is a reply to message #396075] |
Wed, 24 June 2020 00:12 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, June 23, 2020 at 4:22:46 PM UTC+10, Bob Martin wrote:
> On 22 Jun 2020 at 08:13:28, r......@gmail.com wrote:
>> On Monday, June 22, 2020 at 3:43:50 PM UTC+10, Bob Martin wrote:
>>> On 21 Jun 2020 at 15:32:39, Quadibloc <j......@ecn.ab.ca> wrote:
>>>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, r.......@gmail.com wrote:
>>>>
>>>> > The base-displacement addressing model proved to be
>>>> > an impediment, tying up valuable general registers;
>>>> > instruction-relative addressing would have been far better.
>>>>
>>>> Base displacement addressing lets a program call a subroutine that might be
>>>> located at a far-away location in memory, such as, say, a resident library
>>>> routine. You can't do that with only program counter-relative addressing.
>>>>
>>>> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
>>>
>>> +1
>>>
>>> OS/360 had non-blocking I/O from the off in 1964
>>
>> OS/360 and the S/360 were not then in existence.
>
> What are you talking about?
> S/360 was announced in April 1964. I was there.
The announcement is irrelevant. That was a couple of years before
the hardware was even available.
|
|
|
|
| Re: IBM S/360 - 370 [message #396105 is a reply to message #396086] |
Wed, 24 June 2020 00:21 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, June 24, 2020 at 2:23:46 AM UTC+10, Jon Elson wrote:
> r......@gmail.com wrote:
>
>> On Monday, June 22, 2020 at 2:36:52 PM UTC+10, Dan Espen wrote:
>>> r......@gmail.com writes:
>
>>> Sounds to me like you are describing S/360 JUMP instructions.
>>
>> No I'm not.
>> They are base-relative instructions, and suffer from the
>> the same range problems as all the other instructions
>> that use base-displacement addressing.
>>
> In any RX instruction, you can specify a base register of zero,
You cannot "specify a base register of zero".
You can specify zero in the base register field of the instruction,
in which case there is no contribution to the address computation.
Register 0 is never referenced.
Same for the index register field.
> and instead
> of adding the contents of register zero, it is NOT added to the index
> register plus offset. This allows you to use absolute addressing for a
> branch or subroutine call (BALR). This is required when you call a shared
> routine not in your partition.
I was using absolute addressing in the 1970s.
> (In any other RX instruction, you can do the same with a base reg
> specification of zero, to use a stored absolute address to access some
> data.)
You can do that in all RX instructions.
|
|
|
|
| Re: IBM S/360 - 370 [message #396114 is a reply to message #396095] |
Wed, 24 June 2020 11:06 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> writes:
> In article <Sm3IG.21460$zX4.10037@fx41.iad>,
> Scott Lurndal <slp53@pacbell.net> wrote:
>>> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
>>
>> Only if you compare it with the 8088. A modern intel processor is as
>> capable as any modern z-series processor. A flat 64-bit address space is
>> much easier to use efficiently when compared to any segmented architecture.
>
> In terms of instruction set I would generally agree. But for
> industrial strength I/O, the zSeries is still way stronger.
I'm not sure that's the case. For standard PC built around an
Intel processor, I'd agree. But it's quite feasible to build
a multisocket intel system with equivalent I/O (and without channel programs :-).
Given the number of lanes of 4G PCI-Express available on high-end xeon
processors, modern 16Gb fiberchannel, 100Gb ethernet, Intel systems can
be very powerful. Heck, all the old burroughs and sperry systems are now
emulated on high-end xeon based systems by Unisys.
There even ARM SOCs with dozens of processors, multiple 100Gbit ethernet
and significant number of PCI-Express lanes.
IBM's strength is backwards compatbility.
|
|
|
|
| Re: IBM S/360 - 370 [message #396131 is a reply to message #396114] |
Wed, 24 June 2020 21:43 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <HZJIG.25206$lI.22170@fx22.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>>> Only if you compare it with the 8088. A modern intel processor is as
>>> capable as any modern z-series processor. A flat 64-bit address space is
>>> much easier to use efficiently when compared to any segmented architecture.
>>
>> In terms of instruction set I would generally agree. But for
>> industrial strength I/O, the zSeries is still way stronger.
>
> I'm not sure that's the case. For standard PC built around an
> Intel processor, I'd agree. But it's quite feasible to build
> a multisocket intel system with equivalent I/O (and without channel programs :-).
It's not just the speed, it's the whole design that has enough
redundancy to recover from nearly any possible failure. A Z system has
hot spare CPUs that can take over for a failing one in the middle of
an instruction. They similarly have multiple paths to I/O devices so
if one fails, it can recover on the fly.
> IBM's strength is backwards compatbility.
That and reliability. There have been TPF systems that have stayed up
continuously for over 10 years, through multiple hardware and software
upgrades.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: IBM S/360 - 370 [message #396132 is a reply to message #396131] |
Wed, 24 June 2020 22:01 |
|
|
Originally posted by: J. Clarke
On Thu, 25 Jun 2020 01:43:22 -0000 (UTC), John Levine
<johnl@taugh.com> wrote:
> In article <HZJIG.25206$lI.22170@fx22.iad>,
> Scott Lurndal <slp53@pacbell.net> wrote:
>>>> Only if you compare it with the 8088. A modern intel processor is as
>>>> capable as any modern z-series processor. A flat 64-bit address space is
>>>> much easier to use efficiently when compared to any segmented architecture.
>>>
>>> In terms of instruction set I would generally agree. But for
>>> industrial strength I/O, the zSeries is still way stronger.
>>
>> I'm not sure that's the case. For standard PC built around an
>> Intel processor, I'd agree. But it's quite feasible to build
>> a multisocket intel system with equivalent I/O (and without channel programs :-).
>
> It's not just the speed, it's the whole design that has enough
> redundancy to recover from nearly any possible failure. A Z system has
> hot spare CPUs that can take over for a failing one in the middle of
> an instruction. They similarly have multiple paths to I/O devices so
> if one fails, it can recover on the fly.
>
>
>> IBM's strength is backwards compatbility.
>
> That and reliability. There have been TPF systems that have stayed up
> continuously for over 10 years, through multiple hardware and software
> upgrades.
OTOH, our IT reboots everything once a week, whether it needs it or
not and whether it's in the middle of a critical-path job or not.
|
|
|
|
| Re: IBM S/360 - 370 [message #396133 is a reply to message #396132] |
Wed, 24 June 2020 22:05 |
Richard Thiebaud
Messages: 222
Registered: May 2013
Karma: 0
|
Senior Member |
|
|
On 6/24/20 10:01 PM, J. Clarke wrote:
> On Thu, 25 Jun 2020 01:43:22 -0000 (UTC), John Levine
> <johnl@taugh.com> wrote:
>
>> In article <HZJIG.25206$lI.22170@fx22.iad>,
>> Scott Lurndal <slp53@pacbell.net> wrote:
>>>> > Only if you compare it with the 8088. A modern intel processor is as
>>>> > capable as any modern z-series processor. A flat 64-bit address space is
>>>> > much easier to use efficiently when compared to any segmented architecture.
>>>>
>>>> In terms of instruction set I would generally agree. But for
>>>> industrial strength I/O, the zSeries is still way stronger.
>>>
>>> I'm not sure that's the case. For standard PC built around an
>>> Intel processor, I'd agree. But it's quite feasible to build
>>> a multisocket intel system with equivalent I/O (and without channel programs :-).
>>
>> It's not just the speed, it's the whole design that has enough
>> redundancy to recover from nearly any possible failure. A Z system has
>> hot spare CPUs that can take over for a failing one in the middle of
>> an instruction. They similarly have multiple paths to I/O devices so
>> if one fails, it can recover on the fly.
>>
>>
>>> IBM's strength is backwards compatbility.
>>
>> That and reliability. There have been TPF systems that have stayed up
>> continuously for over 10 years, through multiple hardware and software
>> upgrades.
>
> OTOH, our IT reboots everything once a week, whether it needs it or
> not and whether it's in the middle of a critical-path job or not.
>
Does your IT use IBM?
|
|
|
|
| Re: IBM S/360 - 370 [message #396134 is a reply to message #396131] |
Wed, 24 June 2020 22:10 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> writes:
> In article <HZJIG.25206$lI.22170@fx22.iad>,
> Scott Lurndal <slp53@pacbell.net> wrote:
>>>> Only if you compare it with the 8088. A modern intel processor is as
>>>> capable as any modern z-series processor. A flat 64-bit address space is
>>>> much easier to use efficiently when compared to any segmented architecture.
>>>
>>> In terms of instruction set I would generally agree. But for
>>> industrial strength I/O, the zSeries is still way stronger.
>>
>> I'm not sure that's the case. For standard PC built around an
>> Intel processor, I'd agree. But it's quite feasible to build
>> a multisocket intel system with equivalent I/O (and without channel programs :-).
>
> It's not just the speed, it's the whole design that has enough
> redundancy to recover from nearly any possible failure. A Z system has
> hot spare CPUs that can take over for a failing one in the middle of
> an instruction. They similarly have multiple paths to I/O devices so
> if one fails, it can recover on the fly.
To be fair, multipath I/O is fairly straightforward with fiberchannel or
infiniband. Having built such machines around AMD and Intel processors a decade
ago, I know that it's possible, if expensive.
Linux has supported hot-spare CPU for more than a decade (hot plug and unplug);
we used that capability in our system to shift resources between systems on
demand.
Back in my Burroughs days, multipath I/O was more about bandwidth[*] than
reliability, but served both purposes. Again on those systems hardware
could be removed and added without rebooting (halt/loading) the operating
system.
[*] Early versions of the B4800 family MCP could only submit a single
I/O request per channel, so to get multiple spindles on a pack string
transferring in parallel required multipath controllers and special
units called 'exchanges' that allowed 8 channels to a string of 16
spindles. Those 8 channels could be from a single host or from up
to four separate hosts (loosely coupled) sharing the storage, with
hardware block locking between the four systems (file protect memory
and later shared system processor).
Later versions of the MCP could queue requests to the I/O processor
which allowed multiple requests per channel to be in process in
parallel (although having multipath did increase bandwidth and reduce
contention for the channel).
|
|
|
|
Members
Search
Help
Register
Login
Home
