Relocating application architecture and compiler support - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Relocating application architecture and compiler support

Quoted text here. Click to load it

For the S/370 models after the 155 and 165, there was virtual memory/paging
support, so such things were either eiasier or not needed.  For S/360, I
don't see how it could work given that the instructions had a base register
number included in them and if the program was relocated, the contents of
that register would have to change, but the OS doesn't know which registers
to change.  Can you explain in more detail how that worked?

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



Re: Relocating application architecture and compiler support

Quoted text here. Click to load it

I haven't written any 360/370 assembler for more than 20 years, though I used
to be pretty good at it, so details may be a tad rusty.

[NB:  I started to do this from memory, then decided that Al Kossow could help
    immensely, and I was right:  Cf. page 37 of

    http://bitsavers.org/pdf/ibm/360/C20-6503-0_BAL_Feb65.pdf

     Thanks again for your preseveration efforts, Al!  --rma
]

The start of any assembler program was an instruction to assign a base address
to a register, followed by one or more USING statements to assign one or more
base registers starting with the one in the instruction just mentioned.  The
convention for OS/360 and its descendants was to use register 12, as in

    BALR 12,0
    USING *,12

which caused the system to place the current location into 12 and then assign
implied addresses against it.  Additional base registers could be assigned if
needed due to code size:

    BALR 12,0
    USING *,12
    BAL 11,4095(12)
    LA 11,1(11)
    USING *+4096,11
    ...

So the code was automagically relocatable, since the base register(s) were
given the correct value by the system at execution time--not by the OS, but by
the hardware itself.

--
Rich Alderson                                       | /"\ ASCII ribbon     |
snipped-for-privacy@alderson.users.panix.com                       | \ / campaign against |
We've slightly trimmed the long signature. Click to see the full one.
Re: Relocating application architecture and compiler support
Quoted text here. Click to load it
         ^^^ LA 11,4095(12) Two instructions required
                            since displacements limited to 12 bits.

Quoted text here. Click to load it

This is more of a DOS-ism.  Under OS all programs are called with the
entry point address in register 15, so you can use
       ENTRY AAA
   AAA LR 12,15
       USING AAA,12


Re: Relocating application architecture and compiler support

Quoted text here. Click to load it

Snipped examples.  This, and the following posts, miss the point.  I know
that the code could be loaded anywhere in memory for execution.  The point
was that once it was loaded, it could not be moved to some other physical
location in memory because the actual physical address was in some user
registers and the OS couldn't know which ones and thus could not change them
of it wanted to move the program.

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



Re: Relocating application architecture and compiler support

Quoted text here. Click to load it

Lynn's example is not relocateable to the level you are thinking- that
is, relocateable at an interrupt level.  Once execution starts, virtual
(not physical) memory addresses must stay put.

The relocatabilty you are talking about can be done, but it would be
enormously difficult and a PIA. It would mean that all memory (address)
references must be atomic.  E.g.

->  read address from memory

->  do some complex calculation based on the address to get a new address

->  read memory at the new address

could not be done, because at any point between the 1st and 3rt bullet,
an interrupt could have happened, rendering the calculation moot.  This
is much more than simply knowing which registers contain addresses- no
addresses at all in memory would be allowable *in the entire application
  address space*.

But I don't see any value to the level of relocateabiltiy you are
discussing.

Edward Wolfgram

Re: Relocating application architecture and compiler support
Quoted text here. Click to load it

i had a very simple objective that the executable program image on
disk would be identical to the executable program image in virtual
memory and that the same executable program image could appear (using
virtual memory segment sharing) could appear concurrently in multiple
different virtual address spaces at potentially different virtual
addresses.

each active, executing context of that executable program image (in
360) could have location specific bindings (like addresses in
registers) ... but the storage image of the executable program would
not.

os/360 conventions peppered the program image with things called
relocatable address constants ... which would be swizzled to an
address/location specific value when the program was brought into real
storage (or mapped into virtual address space) before actual execution
began.

tss/360 accomplished the objective by collecting the relocatable
address constants (needing any swizzling) into a different structure
that could be private to a specific executable instance ... but wasn't
part of the instruction program image.

For the stuff i did, i made due with various programming hacks to
resolve things relative to content of some register .... and in 360,
it is possible to establish the specific register executable instance
contents with mechanisms like BALR reg,0.

this is somewhat analogous to different threads executing the same
exact code tending to have their private instance execution
environment .... even though the exact same common code is being
executed ,,,, and extending the private instance execution environment
to include instance specific location of the (same) executable code.

in both cp67 and vm370 (360, 370 and later), the virtual memory
relocation mechanism allowed placement of virtual storage pages at
randomly (and potentially varying) real storage locations
... transparent to the application.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn /

Re: Relocating application architecture and compiler support

Quoted text here. Click to load it



Different objectives have been discussed in this thread, both
with and without S/370 style DAT.   If one wanted to do
timesharing on S/360 including relocating programs as they were
swapped in and out, something more complex would be required,
possibly including conventions on register use.

It was nice of S/370 to come along when it did to remove the
need for that problem.

-- glen


Re: Relocating application architecture and compiler support
Quoted text here. Click to load it

note the original base/bound stuff that boeing used to do swapping of
contiguous memory ... may have been in the microcode of some number of
(360/50) machines possibly associated with emulation (1401, 7094, etc)
... as opposed to some custom microprograming that they had done.

it was possible to get custom microprogramming support on many of
these machines. I think it was Lincoln Labs may have originated the
search-list (SLT) instruction that was installed on some number of the
360/67s.

the boston programming center in support of the conversational
programming system (CPS) ... interactive PLI and BASIC that ran under
relative vanilla os/360 ... had done a custom RPQ microcode package
that could be had for 360/50 ... that was performance acceleration for
doing interpretive execution. I don't know the details of how CPS
handled swap-in/swap-out ... it is possible that they controlled a lot
more of program execution ... they could control the instruction image
not having embedded location specific information and knew what
registers in the private execution context needing swizzling when
swap-out/swap-in sequence didn't bring back to the same swap address.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn /

Re: Relocating application architecture and compiler support
may have used oatmeal boxes, old string,
and new, used, and recycled electrons to say (at least in part):

Quoted text here. Click to load it

The /50 emulated only the 1410/7010 and the 7070/74.  No 709x (with a 4
byte wide memory, performance projections were dismal) and no 1401 (left
to the /30 and /40).

There was no microcode assist for memory swapping in these emulators.
There might have been (I don't know one way or the other) in a microcode
RPQ that was done for a timesharing company (AB).
 
--
 Julian Thomas:   jt@jt-mj.net    http://jt-mj.net
 In the beautiful Finger Lakes Wine Country of New York State!
We've slightly trimmed the long signature. Click to see the full one.
Re: Relocating application architecture and compiler support
Quoted text here. Click to load it

this is really vague recollection .. there was something about
partitioning some memory (using base&bound specification) and invoking
emulation using diagnose instruction ... and the gimick was how to
specify base&bound (with diagnose) while still staying in 360 mode
(aka it wasn't originally intended for swapping or time-sharing ...  I
have vague recollection it had something to do with emulation).

there is a small off-chance that i have a page or two write-up in some
pile of paper someplace. if i get this scanning stuff down ... i'll
try and find it.

on the other hand ... microcode RPQs weren't that uncommon.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn /

Re: Relocating application architecture and compiler support

Quoted text here. Click to load it

Yes.  That is the point.

Quoted text here. Click to load it

In S/360 and its contemporaries, there was no such thing as "virtual
addresses".

Quoted text here. Click to load it

On S/360 architecture, yes.  But the architecture I described in earlier
posts in this thread did it easily and naturally with no programmer
attention at all.

Quoted text here. Click to load it

No.  Read the description of the system I talked about earlier in this
thread.  Briefly, all addresses visible to the program are "program
relative", that is starting at address zero.  The hardware automatically
adds the contents of a "base register" that is invisible to the program, but
part of its context, to all program addresses to get physical hardware
addresses.

Quoted text here. Click to load it

It is (or I should say was, as virtual memory makes it moot) extremely
valuable.  Say you have several interactive/time sharing users.  You really
want to be able to swap out a program during the "user think time", or even
if it uses up its time quantum, to allow another user to use the memory.
But this is very limited if, when a program is swapped out, it must be
swapped back in to the same physical address as it was loaded to originally.
Or the OS just wants to move a program to defragment memory in order to make
more efficient use of it (and perhaps allow another program in).  This can't
really be done without a mechanism like the one I described.

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



Re: Relocating application architecture and compiler support
Quoted text here. Click to load it
had
know
point
physical
them

Execution of what?  An instruction, sure.  But not a program!!

Quoted text here. Click to load it

You have to have them atomic if you want to be able to sleep the
system and have it continue where it left off.
This was one of the features of TOPS-10's SMP implementation.
You could issue the commmand SYSTEM SLEEP, the monitor would
tuck itself in and store its current context on disk, the
operator could add and remove any hardware he wanted to,
and then resume timesharing and the monitor would brush
itself off and continue from the point where it was
temporaily stopped.  We did not reboot!!!!


The point is to be able to reconfigure on the fly without
causing all programs to have to restart.

Quoted text here. Click to load it

So?  Not all interrupts would affect this calculation.

Quoted text here. Click to load it

There is lots of value.  You guys seem to be confusing OS
execution, user program execution and instruction execution.


/BAH

Subtract a hundred and four for e-mail.

Re: Relocating application architecture and compiler support

Quoted text here. Click to load it
.
.

I was under the impression that we are discussing relocation in the
context of changing virtual (or real, in a non VM machine) addresses of
both the program *and* the data the program is using.  Thus, at an
interruption, we can swap a user's context (program and data) at will to
  another location in memory. Relocation of just the program is not
difficult- just make it reentrant without adcons.  But the data, to be
relocateable, also cannot contain addresses.

But perhaps I'm confused, in which case please elaborate.

Edward Wolfgram


Re: Relocating application architecture and compiler support

(snip)

Quoted text here. Click to load it

That is one of the forms being discussed.

To add another, consider the U option of the OS/360 DSORG DCB
parameter: unmovable.  There were files that contained absolute
disk addresses (cylinder, track, record), and so couldn't be
moved to a different location on the disk.  If a backup was made
it had to be able to be restored to the same position on the new
disk.

Relocation isn't just for running programs stored in real or
virtual storage.

-- glen


Re: Relocating application architecture and compiler support

Where are you posting from?  There's been a complaint about
posting this to c.a.e.  And I always get kicked out of c.a.

Quoted text here. Click to load it

It appears that sometimes you all are discussing this flavor.
It also appears that you're discussing other flavors.  Note
that what I know about hardware and how OSes do this stuff
is miniscule.

Changing addresses of data over a course of execution
shouldn't matter if it's the user program.  In certain
cases it does matter if this data is the OS's data it
needs when it's executing in exec mode.

I'm using TOPS-10 terminology here because I don't know
how to speaketh in Unix nor IBM tongues.

Quoted text here. Click to load it

Nope that (swap) takes too long.  At monitor that knows its job
will store the address of the user's page map page on its stack.
If the data and/or program needs to be moved or swapped for
any reason, this work is done once the interrupt is dismissed.

I don't think it's ever done at interrupt level...I can't think
of a scenario when swap and/or moving is done.  In the computing
biz, there is always an exception to every rule...including this
one :-).

Quoted text here. Click to load it

It can't contain absolute addresses without special handling,
where special only means very careful handling.

Quoted text here. Click to load it

I don't think you're confused but I do think each person is
talking about a different side of an eight-sided coin.
IME, when this happens everybody thinks they're talking about
the same problem and are conveying information about the
problem, but aren't.


/BAH

Subtract a hundred and four for e-mail.

Re: Relocating application architecture and compiler support
Quoted text here. Click to load it

This is all OT on comp.arch.embedded.  Please set followups on any
further entries in this thread to eliminate c.a.e.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on
We've slightly trimmed the long signature. Click to see the full one.
Re: Relocating application architecture and compiler support

[I'm restricting followups to a.f.c, because this seems to have deviated
from the interests of comp.arch.*; feel free to set them back if you
disagree.]

Quoted text here. Click to load it

Versions of MS Windows prior to full virtual memory support - ie
before Windows 95[*] - essentially did the same thing.  The memory
allocation routines would return memory "handles".  To get a pointer
you made another call to "lock" the handle; then the region would be
fixed in memory until you unlocked at - at which time it could be
moved by the OS (such as it was) to another location.

There were a couple of different varieties of memory locking so that,
for example, a process could tell Windows that it expected to keep an
area locked for a while and so it should be put in an area where it
was less likely to cause fragmentation.  This was useful for IPC;
since processes were running in the same address space, you could
allocate and lock a region in one process, send the address to
another process in a Windows message, and then they could share the
area.

All completely unsafe if there was any program misbehavior, of course,
but that's what you had with Windows.  These days Windows has virtual
memory and other goodies and remains completely unsafe; this is called
"progress".


*Windows 3.0 and Windows for Workgroups had "386 Enhanced Mode",
which provided some virtual memory support, but I can't remember how
far it went.  It might have run programs in separate virtual-86
regions.  No doubt someone here recalls the details, or cares enough
to look them up.

--
Michael Wojcik                   snipped-for-privacy@microfocus.com

Auden often writes like Disney.  Like Disney, he knows the shape of beasts --
We've slightly trimmed the long signature. Click to see the full one.
Re: Relocating application architecture and compiler support

Quoted text here. Click to load it

I was going to say something like this, but then I reread Stephen's
comments about the system-base-register being part of the program's
context.  Possibly he was thinking of the equivalent of LINK macro
resetting the register for each call/return.  Then, of course, it blows
away any access to the other program's data.


Re: Relocating application architecture and compiler support
Quoted text here. Click to load it

It can't be moved while executing because the monitor is the
one whose code is getting executed to do that shuffling task.

/BAH

Subtract a hundred and four for e-mail.

Re: Relocating application architecture and compiler support

(snip, I wrote)

Quoted text here. Click to load it


Well, that was supposed to include during interrupts.

-- glen


Site Timeline