Re: S/390 (was Market pressures for more reliable software)

Re: S/390 (was Market pressures for more reliable software)

[robin]

Roedy Green <roedy@mindprod.com> writes: > On Thu, 28 Jun 2001 04:01:02 GMT, robin <robin_v@bigpond.nospam.com>
> wrote or quoted :
> 
> >> To load you had to adjust all the
> >> address references to account for where in RAM the program was loaded.
> >
> >No, only those words that had been specified as containing an absolute
> >address.
> 
> you only had a 12 bit displacement, so you needed great many ADCONS
> (address constants),

I'm aware that the displacement is 12 bits, having used the
assembley language for many years.
However, my original post mentioned program-relative addressing
as one of the modes.  With the BALR instruction, one or
more registers can be loaded with the absolute address of the next
instruction.  This register(s) can then be used as the
base register(s).  No address constants needed.

The number of address constants depends on the programmer.
There might be none or very few such constants.  Certainly not enough to
significantly increase program load time.

> to fill your base registers with before you could
> get at anything. On load, all these had to be adjusted to account for
> where the program was actually loaded in RAM.

Several instructions, requiring very little execution time.

> Roedy Green, Canadian Mind Products

Re: S/390 (was Market pressures for more reliable software)

[Gary Labowitz]

And, of course, there was LA *-4 used all the time for base registers on the
fly.
Gary
"robin" <robin_v@bigpond.nospam.com> wrote in message
news:xME_6.9627$e5.27883@newsfeeds.bigpond.com...
> Roedy Green <roedy@mindprod.com> writes: > On Thu, 28 Jun 2001 04:01:02
GMT, robin <robin_v@bigpond.nospam.com>
> > wrote or quoted :
> >
> > >> To load you had to adjust all the
> > >> address references to account for where in RAM the program was
loaded.
> > >
> > >No, only those words that had been specified as containing an absolute
> > >address.
> >
> > you only had a 12 bit displacement, so you needed great many ADCONS
> > (address constants),
>
> I'm aware that the displacement is 12 bits, having used the
> assembley language for many years.
> However, my original post mentioned program-relative addressing
> as one of the modes.  With the BALR instruction, one or
> more registers can be loaded with the absolute address of the next
> instruction.  This register(s) can then be used as the
> base register(s).  No address constants needed.
>
> The number of address constants depends on the programmer.
> There might be none or very few such constants.  Certainly not enough to
> significantly increase program load time.
>
> > to fill your base registers with before you could
> > get at anything. On load, all these had to be adjusted to account for
> > where the program was actually loaded in RAM.
>
> Several instructions, requiring very little execution time.
>
> > Roedy Green, Canadian Mind Products

Re: S/390 (was Market pressures for more reliable software)

[Roedy Green]

On Thu, 28 Jun 2001 11:44:29 GMT, robin <robin_v@bigpond.nospam.com>
wrote or quoted :

>With the BALR instruction, one or
>more registers can be loaded with the absolute address of the next
>instruction.  This register(s) can then be used as the
>base register(s).  No address constants needed.

The BALR was S/360's rather odd subroutine jump instruction.

BALR 14,15 would put the return address in reg 14 and jump to the
subroutine addressed by reg 15.

There was no hardware stack.  If the called routine was not a leaf
routine it that to call GETMAIN to allocate a block of RAM to store
the regs, and when it was done call FREEMAIN to give it back.  OUCH.

However, when the subroutine was a leaf (called no methods), this was
very efficient, because you could return without having to access
ram/stack, just look in R14. 

Now to bring this back to JAVA.  I thought there should be special
optimisations for calls to Java leaf routines where the return address
is left in a register, and the usual overhead of creating a stack
frame is bypassed. This would be analogous to the old S/360 BALR
14,15.

Clever lookahed logic in hardware could then get you your subroutine
return for free.

I did an optimisation of this form in my BBL Forth compiler.  It made
a huge difference on the old 8086 that did not have an optimised
stack-based call/ret.  Chuck Moore's SHBOOM chip reserved a bit in
each operand for piggybacking a ret.

The Pentium has such a well optimised CALL/RET using this trick would
not buy you anything. However, it might be something clever to try in
a Picojava processor.




For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: S/390 (was Market pressures for more reliable software)

[robin]

Roedy Green <roedy@mindprod.com> writes: > On Thu, 28 Jun 2001 11:44:29 GMT, robin <robin_v@bigpond.nospam.com>
> wrote or quoted :
> 
> >With the BALR instruction, one or
> >more registers can be loaded with the absolute address of the next
> >instruction.  This register(s) can then be used as the
> >base register(s).  No address constants needed.
> 
> The BALR was S/360's rather odd subroutine jump instruction.
> 
> BALR 14,15 would put the return address in reg 14 and jump to the
> subroutine addressed by reg 15.

But when the second address is zero, it does not branch, and
the address of the next instruction is placed in the nominated
register.  (e.g., BALR 3,0)

This value (contents) is then used as the base for addressing purposes.

> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

Re: S/390 (was Market pressures for more reliable software)

[Roedy Green]

On Thu, 28 Jun 2001 23:17:43 GMT, robin <robin_v@bigpond.nospam.com>
wrote or quoted :

>But when the second address is zero, it does not branch, and
>the address of the next instruction is placed in the nominated
>register.  (e.g., BALR 3,0)


It is quite amazing that people can still remember this stuff.  I have
not used it since the 70s.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: S/390 (was Market pressures for more reliable software)

[John Homes]

"Roedy Green" <roedy@mindprod.com> wrote in message
news:fcgnjt4ft33trc0qvudsii54todsmt2e9u@4ax.com...
> On Thu, 28 Jun 2001 23:17:43 GMT, robin <robin_v@bigpond.nospam.com>
> wrote or quoted :
>
> >But when the second address is zero, it does not branch, and
> >the address of the next instruction is placed in the nominated
> >register.  (e.g., BALR 3,0)
>
>
> It is quite amazing that people can still remember this stuff.  I have
> not used it since the 70s.
>

Some of us are still using it..

    John Homes.

Re: S/390 (was Market pressures for more reliable software)

[Randy Hudson]

In article <9hght3$c3s$1@hermes.nz.eds.com>,
 John Homes <John.Homes@eds.com> wrote:

> Some of us are still using it..

Before I used BALR, I used an even odder subroutine call, JMS on DEC's PDP-8
series (it was the same on the PDP-5, but, thankfully, I'm not old enough to
have programmed that one). The PAL-III assembler didn't directly support
reloation (object files were only loadable to the addresses they were
assembled to), but we wrote some helper routines that we could call as a
subroutine, which would update the relocation constants of the page from
which it was called, and then return to that page; the JMS instruction (it
stored the program counter at the pointed-to location, then jumped to the
following instruction) was central to that routine.

Modern computer architecture theorists would use the PDP-8 as an example of
how not to design a CPU.

SABR came out soon after that, which had its own methods for creating
relocatable object code for the PDP-8.

-- 
Randy Hudson  <ime@netcom.com>

Re: S/390 (was Market pressures for more reliable software)

[hack]

In article <9hght3$c3s$1@hermes.nz.eds.com>,
John Homes <John.Homes@eds.com> wrote:
>
>"Roedy Green" <roedy@mindprod.com> wrote in message
>news:fcgnjt4ft33trc0qvudsii54todsmt2e9u@4ax.com...
>> On Thu, 28 Jun 2001 23:17:43 GMT, robin <robin_v@bigpond.nospam.com>
>> wrote or quoted :
>>
>> >But when the second address is zero, it does not branch, and
>> >the address of the next instruction is placed in the nominated
>> >register.  (e.g., BALR 3,0)
>>
>>
>> It is quite amazing that people can still remember this stuff.  I have
>> not used it since the 70s.
>>
>
>Some of us are still using it..
>
>    John Homes.

Some of us may even "abuse" it, e.g.

    BALR 3,0   (Head of do-it-twice loop)
    ....       whatever (that leaves R3 alone)
    BALR 3,3   Go back once

Michel

Re: S/390 (was Market pressures for more reliable software)

[Gary Labowitz]

What's even more amazing is that I can recall a number of the op codes.
Gary
"Roedy Green" <roedy@mindprod.com> wrote in message
news:fcgnjt4ft33trc0qvudsii54todsmt2e9u@4ax.com...
> On Thu, 28 Jun 2001 23:17:43 GMT, robin <robin_v@bigpond.nospam.com>
> wrote or quoted :
>
> >But when the second address is zero, it does not branch, and
> >the address of the next instruction is placed in the nominated
> >register.  (e.g., BALR 3,0)
>
>
> It is quite amazing that people can still remember this stuff.  I have
> not used it since the 70s.
>
>
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
>
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

Re: S/390 (was Market pressures for more reliable software)

[Clem Clarke]

As I recall, PCP, MFT, VS1, VS2 and MVS all relocated the code for you at
load time.

However, you had to do it all yourself for DOS.

Clem


Roedy Green wrote:

> On Thu, 28 Jun 2001 23:17:43 GMT, robin <robin_v@bigpond.nospam.com>
> wrote or quoted :
>
> >But when the second address is zero, it does not branch, and
> >the address of the next instruction is placed in the nominated
> >register.  (e.g., BALR 3,0)
>
> It is quite amazing that people can still remember this stuff.  I have
> not used it since the 70s.
>
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
>
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

--


  ,-._|\  Clement V. Clarke - Author Jol, EASYJCL, EASYPANEL, OSCAR,
370TO486
 /  Oz  \ oscarptyltd@ozemail.com.au, Web:
http://www.ozemail.com.au/~oscarptyltd
 \_,--.x/ P.O. Box 628, Toorak, Victoria, AUSTRALIA, 3142.
       v  Tel (61)-3-9815-2311, A/H 9818-8351, Fax (61)-3-9819-2848.

Re: S/390 (was Market pressures for more reliable software)

[Shmuel (Seymour J.) Metz]

In <fcgnjt4ft33trc0qvudsii54todsmt2e9u@4ax.com>, on 06/28/2001
   at 11:46 PM, Roedy Green <roedy@mindprod.com> said:

>It is quite amazing that people can still remember this stuff.  I
>have not used it since the 70s.

I still remember stuff from the 650. But not with nostalgia :-(


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: S/390 (was Market pressures for more reliable software)

[Shmuel (Seymour J.) Metz]

In <rWO_6.10272$e5.30402@newsfeeds.bigpond.com>, on 06/28/2001
   at 11:17 PM, robin <robin_v@bigpond.nospam.com> said:

>But when the second address is zero, it does not branch, and the
>address of the next instruction is placed in the nominated register. 
>(e.g., BALR 3,0)

>This value (contents) is then used as the base for addressing
>purposes.

And that is the standard way to establish addressability when there
isn't a register known to contain a suitable base. 

ObBadCode. SVC 18 used to contain a sequence something like

         BALR  R3,0
         BALR  R3,0
         BALR  R3,0
         USING *,R3

which contains two extraneous instructions.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: S/390 (was Market pressures for more reliable software)

[Randy Hudson]

[ posted and emailed ]

In article <3b3c7267$8$fuzhry$mr2ice@va.news.verio.net>,
 Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:

> ObBadCode. SVC 18 used to contain a sequence something like
> 
>          BALR  R3,0
>          BALR  R3,0
>          BALR  R3,0
>          USING *,R3
> 
> which contains two extraneous instructions.

Are you sure that wasn't:

SVC18    BALR  3,0
         BCTR  3,0
         BCTR  3,0
         USING SVC18,3

? That sequence sets the base register to the entry point, which used to be
considered good for debugging reasons.  

-- 
Randy Hudson  <ime@netcom.com>

Re: S/390 (was Market pressures for more reliable software)

[Shmuel (Seymour J.) Metz]

In <9hjqmv$a0e$1@news.panix.com>, on 06/30/2001
   at 06:13 AM, Randy Hudson <ime@netcom.com> said:

>Are you sure that wasn't:

>SVC18    BALR  3,0
>         BCTR  3,0
>         BCTR  3,0
>         USING SVC18,3

Yes. 


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------