Re: Relocating application architecture and compiler support

From: Stephen Fuld (s.fuld_at_PleaseRemove.att.net)
Date: 01/22/05 

Date: Fri, 21 Jan 2005 23:52:02 GMT

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:css1bm$s75$1@gnus01.u.washington.edu...
> Stephen Fuld wrote:
> (snip)
>
>> Certainly on S/360, but not on other then contemporary architectures.
>> All that is needed is a protected "system base regiser" which is part of
>> the program's context, to which the hardware adds all program addresses.
>> Then all programs can start at zero and go to whatever, and all that is
>> needed if the OS needs to move a program in mid execution is to change
>> the base register.
>
> But there is one thing that OS/360 does easily that is hard in
> other systems, which is what the LINK macro does. To take another
> program, load it into the same address space, execute it (with the
> original still addressable) and then return.

In the interests of simplicity, I left out a few things. In the first
implementation that I know about, there were two "base registers", typicaly
one for instructions and one for data. There was an instruction to "link"
to another chunk of code. The typical mechanism for things like access
methods, was to keep the same data area and link to the code, replacing the
user program code temporarily. Thus the access method code could access the
user program data just fine. When it was done with whatever it had to do,
ir executed the instruction to return to the user code and replace the base
address with the original one. Later models added a second set of two base
registers that allowed further flexibility for more complex schemes. Even
later ones had more features that moved the architecture more toward a
segment scheme (with up to 16 active segments out of something like 32K
total available) that is totally independent of the (later introduced)
paging mechansim.

> I remember TOPS-10, where each program was loaded with virtual origin of
> 0. There was a system for sending files to the print queue which involved
> writing the entire address space to disk, running the QUEUE program with
> an option to execute a program when it was done, which would then reload
> and continue on.

Yuck! That sounds awfull. It seems far simpler for the program to write
the file to disk and simply pass a file name to the printer writer. But I
am sure there were other constraints that I just don't know about.

> Any system with a fixed load point can't have two programs in the same
> address space at the same time.

Actually it can, but it takes some doing, like the hardware I talked about
above, or a convention about using different parts of the address space.
With the extra hardware, it isn't much of a problem.

One extra advantage of the scheme I an taliking abouit is that there is no
need for the "address swizzling stuff" on load that was required by OS/360.
That speeded up program loads.

> In the OS/360 case, besides doing LINK, many routines, especially access
> methods, were directly addressable somewhere in system space. Now, there
> are systems which reserve parts of the address space for system and parts
> for user, but that doesn't help LINK.

Right. See above. 

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

Relevant Pages

  • Re: Insufficient guarantees for null pointers?
    ... guaranteed to be portable and execute "as expected", ... performance on a wider variety of platforms. ... implementing it on existing hardware. ... defines a virtual machine, just two stacks. ...
    (comp.std.c)
  • Re: [Full-disclosure] Cisco IOS Shellcode Presentation
    ... what code that product should be allowed to execute. ... Hardware has bugs too. ... Arbitrary code execution isn't too hard on the XBox, for instance, even ... that constantly needs feeding, whether it is on a funny-looking ...
    (Full-Disclosure)
  • Re: Program protection - can not be copied
    ... User can not read the program, but how does the system can read and execute ... It seems that there is no any direct method to protect the program from ... If you need to "lock" the image on a specific hardware you'll have to ... (l'indirizzo di reply di questo messaggio non ?valido) ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Insufficient guarantees for null pointers?
    ... guaranteed to be portable and execute "as expected", ... architectures the standard *could* impose more stringent ... Tribble said, "flat memory spaces, single pointer representations, and ... implementing it on existing hardware. ...
    (comp.std.c)