On Thursday, July 7, 2022 at 2:47:27 PM UTC-5, Stephen Fuld wrote:
> Quadibloc wrote:
>
> > On Wednesday, July 6, 2022 at 10:01:31 AM UTC-6, MitchAlsup wrote:
> > > On Wednesday, July 6, 2022 at 2:14:02 AM UTC-5, Quadibloc wrote:
> >
> > > > I'm using the S/360 as a model, rather than using RISC
> > > > architectures as the model.
> > > <
> > > Some of us are trying to nudge you into correcting that deficit.
> >
> > Oh, I have noticed. But basically I view the deficiencies of the
> > 680x0, x86, and modern RISC architectures... as the things they're
> > omitting that the S/360 had.
> OK, so what features specifically did S/360 have that none of the
> others you mentioned had that were so beneficial? Surely it was more
> than just the limit to the displacement field of the 68020.
>
> Remember, the original reason for base registers was to allow multiple
> programs to be run in different locations in memory without the
> programmer having to code for specific real addresses. Of course S/360
> was a "real memory" machine - no paging, etc. So a program had to
> execute a BALR instruction right at the beginning to "capture" the read
<
BALR gave a pointer to the code that was executing so you could perform
branching. IP-relative is a much more convenient form for modern machines.
<
> address of where the program was atually loaded, then use that "base"
> for all subsequent references. Other vendors used different solutions
> for this problem, e.g. base register that was not visible to the
> program but saved in say its register save area and was loaded by the
> OS along with the user registerswhenever it gave control to a use
> program. IMHO, this was a better solution, as it freed a user register
> for other use. And, of course, the need for all of this went away when
> virtual memory with separate address spaces per user became available.
<
This particular feature became irrelevant when paging was introduced.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

According to MitchAlsup <MitchAlsup@aol.com>:
>> Remember, the original reason for base registers was to allow multiple
>> programs to be run in different locations in memory without the
>> programmer having to code for specific real addresses. Of course S/360
>> was a "real memory" machine - no paging, etc. So a program had to
>> execute a BALR instruction right at the beginning to "capture" the read
><
>BALR gave a pointer to the code that was executing so you could perform
>branching. IP-relative is a much more convenient form for modern machines.

Indeed it is but it took quite a while to figure that out and add
relative branches to S/390. I suspect that at the time, it made more
sense to define only one kind of addressing rather than one for code
and one for data. BALR N,0 to load a base register with a pointer
to the current location without branching was a clever hack.

The discussion in the IBMSJ article about S/360 suggests that they
thought that base registers would make it possible to move running
programs and so make relocated virtual memory unnecessary, but they
apparently forgot that there are pointers in memory, too. APL\360 had
enough code discipline that it could swap out a user's data block and
swap it back in somewhere else, but that was very rare.

>> address of where the program was atually loaded, then use that "base"
>> for all subsequent references. Other vendors used different solutions
>> for this problem, e.g. base register that was not visible to the
>> program but saved in say its register save area and was loaded by the
>> OS along with the user registerswhenever it gave control to a use
>> program. IMHO, this was a better solution, as it freed a user register
>> for other use. And, of course, the need for all of this went away when
>> virtual memory with separate address spaces per user became available.
><
>This particular feature became irrelevant when paging was introduced.

Single block relocation like on the PDP-6 and GE 635 was indeed less flexible
than paging, but paging adds new excitement when a code library is loaded
into different places in different processes. TSS/360 had a rather rococo
calling sequence to make that work with separate pointers to code and data.
Modern Unix-ish systems that use ELF executables have things called GOT
and PLT to make that work.

--
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

On Thursday, July 7, 2022 at 1:47:27 PM UTC-6, Stephen Fuld wrote:

> Remember, the original reason for base registers was to allow multiple
> programs to be run in different locations in memory without the
> programmer having to code for specific real addresses. Of course S/360
> was a "real memory" machine - no paging, etc. So a program had to
> execute a BALR instruction right at the beginning to "capture" the read
> address of where the program was atually loaded, then use that "base"
> for all subsequent references. Other vendors used different solutions
> for this problem, e.g. base register that was not visible to the
> program but saved in say its register save area and was loaded by the
> OS along with the user registerswhenever it gave control to a use
> program. IMHO, this was a better solution, as it freed a user register
> for other use. And, of course, the need for all of this went away when
> virtual memory with separate address spaces per user became available.

This is definitely a comment that deserves a reply.

Some programs written for the System/360 included code directives like
this:

USING *,12
USING *+4096,11
USING *+8192,10

This is why I sought to provide a 16 bit displacement instead of a 12 bit one.

But why are base registers needed at all? I suppose one could claim they were only
used for compatibility reasons on the IBM System 360 model 67, which had
Dynamic Address Translation.

But that would hardly be fair. 4,096 bytes is hardly enough for the *entire virtual
address space* of a program, _including_ not only the program itself, and all
its data, but *also* entry points for all the operating system calls, and the shared
subroutines to format output or calculate log and trig functions.

So base registers were still needed on the 360/67, even if DAT meant that every user
program _could_ have its entry point at the same virtual address in its own memory
space - so you _could_ hardcode the start address instead of using BALR.

And, therefore, the reason why _I_ feel I still need base registers should now be
obvious. 64 K may now be enough for at least the _code_ segment of most
routines of any sane size - the Macintosh got away with enforcing a hard 32 K limit
for this on all programs back in the 680x0 days - but some programs will definitely
need larger data segments, and even single arrays that are larger than this, and so
64 K is not large enough for the *virtual address space* of a program.

The base register lets you use the whole of a larger virtual address space. And then,
when you have arrays within that space, the index register lets you access the
individual elements of those.

John Savard

On Thursday, July 7, 2022 at 2:45:05 PM UTC-6, MitchAlsup wrote:

> BALR gave a pointer to the code that was executing so you could perform
> branching. IP-relative is a much more convenient form for modern machines.

BAL, of course, was the subroutine call instruction. So a subroutine call
to the next address let you find out where you where, because that would
be stored as the return address.

The System/360 happened to have a register-to-register form of the Branch
and Link instruction that didn't branch, thus saving a few cycles - BALR.

John Savard

On 7/7/2022 3:55 PM, Quadibloc wrote:
> On Thursday, July 7, 2022 at 1:47:27 PM UTC-6, Stephen Fuld wrote:
>
>> Remember, the original reason for base registers was to allow multiple
>> programs to be run in different locations in memory without the
>> programmer having to code for specific real addresses. Of course S/360
>> was a "real memory" machine - no paging, etc. So a program had to
>> execute a BALR instruction right at the beginning to "capture" the read
>> address of where the program was atually loaded, then use that "base"
>> for all subsequent references. Other vendors used different solutions
>> for this problem, e.g. base register that was not visible to the
>> program but saved in say its register save area and was loaded by the
>> OS along with the user registerswhenever it gave control to a use
>> program. IMHO, this was a better solution, as it freed a user register
>> for other use. And, of course, the need for all of this went away when
>> virtual memory with separate address spaces per user became available.
>
> This is definitely a comment that deserves a reply.

Thank you.

>
> Some programs written for the System/360 included code directives like
> this:
>
> USING *,12
> USING *+4096,11
> USING *+8192,10

Yup. Uses up (I resisted saying wastes) three out of your 16 registers.

>
> This is why I sought to provide a 16 bit displacement instead of a 12 bit one.
>
> But why are base registers needed at all? I suppose one could claim they were only
> used for compatibility reasons on the IBM System 360 model 67, which had
> Dynamic Address Translation.
>
> But that would hardly be fair. 4,096 bytes is hardly enough for the *entire virtual
> address space* of a program, _including_ not only the program itself, and all
> its data, but *also* entry points for all the operating system calls, and the shared
> subroutines to format output or calculate log and trig functions.
>
> So base registers were still needed on the 360/67, even if DAT meant that every user
> program _could_ have its entry point at the same virtual address in its own memory
> space - so you _could_ hardcode the start address instead of using BALR.
>
> And, therefore, the reason why _I_ feel I still need base registers should now be
> obvious. 64 K may now be enough for at least the _code_ segment of most
> routines of any sane size - the Macintosh got away with enforcing a hard 32 K limit
> for this on all programs back in the 680x0 days - but some programs will definitely
> need larger data segments, and even single arrays that are larger than this, and so
> 64 K is not large enough for the *virtual address space* of a program.

Mitch has made the argument, which I believe, that for loads/stores, the
base register is useful 2-3% of the time, and if you have a load/store
architecture, you have the space in the instruction to specify it.
Since S/360 is not load/store, it is a more delicate tradeoff.

But for control transfers, eliminating the base register in the
instruction gives you back enough bits for most of your desired range,
especially if you make the addresses IP relative, and gain one or two
more bits by making the target address on at least a 16 bit boundary, or
perhaps 32 (depending what instruction granularity you support). For
the few cases where this isn't sufficient, you could add a jump/branch
to an address that is an offset from a register, but then you only need
that register for one or two instructions, not all the time.

For proof that all this can work, see just about every other
architecture since S/360.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Thursday, July 7, 2022 at 7:15:30 PM UTC-5, Stephen Fuld wrote:
> On 7/7/2022 3:55 PM, Quadibloc wrote:
> > On Thursday, July 7, 2022 at 1:47:27 PM UTC-6, Stephen Fuld wrote:
> >
> >> Remember, the original reason for base registers was to allow multiple
> >> programs to be run in different locations in memory without the
> >> programmer having to code for specific real addresses. Of course S/360
> >> was a "real memory" machine - no paging, etc. So a program had to
> >> execute a BALR instruction right at the beginning to "capture" the read
> >> address of where the program was atually loaded, then use that "base"
> >> for all subsequent references. Other vendors used different solutions
> >> for this problem, e.g. base register that was not visible to the
> >> program but saved in say its register save area and was loaded by the
> >> OS along with the user registerswhenever it gave control to a use
> >> program. IMHO, this was a better solution, as it freed a user register
> >> for other use. And, of course, the need for all of this went away when
> >> virtual memory with separate address spaces per user became available.
> >
> > This is definitely a comment that deserves a reply.
> Thank you.
> >
> > Some programs written for the System/360 included code directives like
> > this:
> >
> > USING *,12
> > USING *+4096,11
> > USING *+8192,10
> Yup. Uses up (I resisted saying wastes) three out of your 16 registers.
> >
> > This is why I sought to provide a 16 bit displacement instead of a 12 bit one.
> >
> > But why are base registers needed at all? I suppose one could claim they were only
> > used for compatibility reasons on the IBM System 360 model 67, which had
> > Dynamic Address Translation.
> >
> > But that would hardly be fair. 4,096 bytes is hardly enough for the *entire virtual
> > address space* of a program, _including_ not only the program itself, and all
> > its data, but *also* entry points for all the operating system calls, and the shared
> > subroutines to format output or calculate log and trig functions.
> >
> > So base registers were still needed on the 360/67, even if DAT meant that every user
> > program _could_ have its entry point at the same virtual address in its own memory
> > space - so you _could_ hardcode the start address instead of using BALR.
> >
> > And, therefore, the reason why _I_ feel I still need base registers should now be
> > obvious. 64 K may now be enough for at least the _code_ segment of most
> > routines of any sane size - the Macintosh got away with enforcing a hard 32 K limit
> > for this on all programs back in the 680x0 days - but some programs will definitely
> > need larger data segments, and even single arrays that are larger than this, and so
> > 64 K is not large enough for the *virtual address space* of a program.
<
> Mitch has made the argument, which I believe, that for loads/stores, the
> base register is useful 2-3% of the time, and if you have a load/store
> architecture, you have the space in the instruction to specify it.
> Since S/360 is not load/store, it is a more delicate tradeoff.
<
[base+index<<scale+displacement] is used 2%-3% of the time. That is all 3
are 2%-3%; [base+disp] is > 68% and [base+index<<scale] is ~15%
<
>
> But for control transfers, eliminating the base register in the
> instruction gives you back enough bits for most of your desired range,
> especially if you make the addresses IP relative, and gain one or two
> more bits by making the target address on at least a 16 bit boundary, or
> perhaps 32 (depending what instruction granularity you support). For
> the few cases where this isn't sufficient, you could add a jump/branch
> to an address that is an offset from a register, but then you only need
> that register for one or two instructions, not all the time.
>
> For proof that all this can work, see just about every other
> architecture since S/360.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

It appears that Quadibloc <jsavard@ecn.ab.ca> said:
>On Thursday, July 7, 2022 at 2:45:05 PM UTC-6, MitchAlsup wrote:
>
>> BALR gave a pointer to the code that was executing so you could perform
>> branching. IP-relative is a much more convenient form for modern machines.
>
>BAL, of course, was the subroutine call instruction. So a subroutine call
>to the next address let you find out where you where, because that would
>be stored as the return address.

Except you couldn't do that unless you already had a base register set
up that covered the next address, in which case why bother?

>The System/360 happened to have a register-to-register form of the Branch
>and Link instruction that didn't branch, thus saving a few cycles - BALR.

It wasn't just saving a few cycles. There is no way to do the equivalent of
BALR N,0 with a BAL.

--
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

On Thursday, July 7, 2022 at 7:32:02 PM UTC-6, John Levine wrote:
> It appears that Quadibloc <jsa...@ecn.ab.ca> said:

> >BAL, of course, was the subroutine call instruction. So a subroutine call
> >to the next address let you find out where you where, because that would
> >be stored as the return address.

> Except you couldn't do that unless you already had a base register set
> up that covered the next address, in which case why bother?

Oops, you're quite right!

John Savard

On 7/6/2022 10:50 AM, MitchAlsup wrote:
> On Wednesday, July 6, 2022 at 11:22:42 AM UTC-5, Quadibloc wrote:
>> On Wednesday, July 6, 2022 at 10:01:31 AM UTC-6, MitchAlsup wrote:
>>> On Wednesday, July 6, 2022 at 2:14:02 AM UTC-5, Quadibloc wrote:
>>
>>>> I'm using the S/360 as a model, rather than using RISC architectures as the model.
>>> <
>>> Some of us are trying to nudge you into correcting that deficit.
>> Oh, I _have_ noticed. But basically I view the deficiencies of the 680x0, x86, and
>> modern RISC architectures... as the things they're omitting that the S/360 had.
> <
> So did I when architecting My 66000 ISA. But I also took into account the utility of
> the feature with respect to modern compiler technology, and ended up with the
> same 360 ISA model but with 32 registers.

Huh??? ISTM that about the only things you took from the S/360 were
byte addressability and having two registers able to participate in the
address calculation for loads and stores.

On the other hand, things you did differently from S/360 include, but
are not limited to

Fixed length instructions (ignoring the inline constant suffixes)

No storage to storage instructions, except for the late addition of the
MM instruction

No CISCy instructions such as translate and test.

No requirement for a base address in jump/branch instructions.

No separate floating point registers.

Many more. :-)

So calling it the same ISA model seems like a big stretch. :-)

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Friday, July 8, 2022 at 1:28:21 AM UTC-5, Stephen Fuld wrote:
> On 7/6/2022 10:50 AM, MitchAlsup wrote:
> > On Wednesday, July 6, 2022 at 11:22:42 AM UTC-5, Quadibloc wrote:
> >> On Wednesday, July 6, 2022 at 10:01:31 AM UTC-6, MitchAlsup wrote:
> >>> On Wednesday, July 6, 2022 at 2:14:02 AM UTC-5, Quadibloc wrote:
> >>
> >>>> I'm using the S/360 as a model, rather than using RISC architectures as the model.
> >>> <
> >>> Some of us are trying to nudge you into correcting that deficit.
> >> Oh, I _have_ noticed. But basically I view the deficiencies of the 680x0, x86, and
> >> modern RISC architectures... as the things they're omitting that the S/360 had.
> > <
> > So did I when architecting My 66000 ISA. But I also took into account the utility of
> > the feature with respect to modern compiler technology, and ended up with the
> > same 360 ISA model but with 32 registers.
<
> Huh??? ISTM that about the only things you took from the S/360 were
> byte addressability and having two registers able to participate in the
> address calculation for loads and stores.
<
You have to look at my sentence in the context of what I was referring. My 66000
is more like S/360 than Mc 88000. It also has memory to memory move MM, LDM,
STM.
>
> On the other hand, things you did differently from S/360 include, but
> are not limited to
>
> Fixed length instructions (ignoring the inline constant suffixes)
<
Yes, I call this the first word of an instruction the 'instruction specifier'
S/360 had this same concept in the first halfword of an instruction.
>
> No storage to storage instructions, except for the late addition of the
> MM instruction
>
> No CISCy instructions such as translate and test.
>
> No requirement for a base address in jump/branch instructions.
>
> No separate floating point registers.
>
> Many more. :-)
>
> So calling it the same ISA model seems like a big stretch. :-)
<
In the context of RISC-V, My 66000 is significantly closer to S/360 than RISC-V.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)