| Author |
Message |
Guest
|
 Posted:
Thu Jan 27, 2005 5:06 pm Post subject:
Re: Relocating application architecture and compiler support |
|
|
In article <41f6b179$1@ibixwebf.ibi.com>,
Edward Wolfgram <Not_Edward_Wolfgram@notiwaysoftware.com> wrote:
| Quote: |
Stephen Fuld wrote:
"Rich Alderson" <news@alderson.users.panix.com> wrote in message
news:mddhdl68ri8.fsf@panix5.panix.com...
"Stephen Fuld" <s.fuld@PleaseRemove.att.net> writes:
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?
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.
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.
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.
|
Execution of what? An instruction, sure. But not a program!!
| Quote: |
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.
|
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.
| Quote: |
-> 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.
|
So? Not all interrupts would affect this calculation.
| Quote: | .. 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.
|
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. |
|
| Back to top |
|
 |
Nick Maclaren
Guest
|
| Posted:
Thu Jan 27, 2005 7:04 pm Post subject:
Re: Relocating application architecture and compiler support |
|
|
In article <ctarrm$emn$1@newslocal.mitre.org>,
Joe Morris <jcmorris@mitre.org> writes:
|>
|> A transient SVC might start execution in one transient area, then
|> surrender control (for example, to do I/O) and resume execution in
|> a different area. The transient SVC handler was responsible for
|> setting the base register to the appropriate value each time a
|> transient SVC was dispatched.
And the author of the SVC for not saving an address of any of its
code across potential dispatching boundaries!
Regards,
Nick Maclaren. |
|
| Back to top |
|
|
Anne & Lynn Wheeler
Guest
|
| Posted:
Thu Jan 27, 2005 9:53 pm Post subject:
Re: Relocating application architecture and compiler support |
|
|
Joe Morris <jcmorris@mitre.org> writes:
| Quote: | And this discussion dredges up memories of the one type of OS/360
executable that was relocatable on the fly: the transient (Type 3/4)
SVC. Typical systems had multiple transient areas, and the
requirements for a type 3/4 SVC (there wasn't really any difference
between the two types) included a prohibition against any
relocatable constants, a requirement of absolute reentrancy, and a
fixed (R12?) base register.
A transient SVC might start execution in one transient area, then
surrender control (for example, to do I/O) and resume execution in a
different area. The transient SVC handler was responsible for
setting the base register to the appropriate value each time a
transient SVC was dispatched.
|
what i remember from mft/mvt days was that there were (initially?)
two, 2k transient svc areas. part of the issue was that the loader
wasn't involved in reading code into the transient area ... so there
wasn't any ability to perform swizzling operation on any (relocatable)
address constants.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ |
|
| Back to top |
|
|
Julian Thomas
Guest
|
| Posted:
Thu Jan 27, 2005 10:08 pm Post subject:
Re: Relocating application architecture and compiler support |
|
|
In <m31xc8ewx5.fsf@lhwlinux.garlic.com>, on 01/25/05
at 07:39 PM, Anne & Lynn Wheeler <lynn@garlic.com>
may have used oatmeal boxes, old string,
and new, used, and recycled electrons to say (at least in part):
| Quote: | 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)
|
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!
Boardmember of POSSI.org - Phoenix OS/2 Society, Inc http://www.possi.org
-- --
The cost of feathers has risen... Now even DOWN is up! |
|
| Back to top |
|
|
Nicholas O. Lindan
Guest
|
| Posted:
Thu Jan 27, 2005 11:13 pm Post subject:
Re: Relocating application architecture and compiler support |
|
|
"Anne & Lynn Wheeler" <lynn@garlic.com> wrote
| Quote: | Joe Morris <jcmorris@mitre.org> writes:
OS/360 executable ... (Type 3/4) SVC with multiple
transient areas ... mft/mvt ... part of the issue was
that the loader wasn't able to swizzle
|
I'm convinced. I will never understand OS/360 relocation
without getting loaded on gin swizzles.
--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer: Electronics; Informatics; Photonics.
To reply, remove spaces: n o lindan at ix . netcom . com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/ |
|
| Back to top |
|
|
Anne & Lynn Wheeler
Guest
|
| Posted:
Fri Jan 28, 2005 12:07 am Post subject:
Re: Relocating application architecture and compiler support |
|
|
Julian Thomas <jt@jt-mj.net> writes:
| Quote: | 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).
|
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/ |
|
| Back to top |
|
|
Edward Wolfgram
Guest
|
| Posted:
Fri Jan 28, 2005 1:20 am Post subject:
Re: Relocating application architecture and compiler support |
|
|
jmfbahciv@aol.com wrote:
| Quote: | In article <41f6b179$1@ibixwebf.ibi.com>,
Edward Wolfgram <Not_Edward_Wolfgram@notiwaysoftware.com> wrote:
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.
Execution of what? An instruction, sure. But not a program!!
.. |
..
| Quote: |
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.
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.
But I don't see any value to the level of relocateabiltiy you are
discussing.
There is lots of value. You guys seem to be confusing OS
execution, user program execution and instruction execution.
/BAH
|
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 |
|
| Back to top |
|
|
glen herrmannsfeldt
Guest
|
| Posted:
Fri Jan 28, 2005 2:17 am Post subject:
Re: Relocating application architecture and compiler support |
|
|
Edward Wolfgram wrote:
(snip)
| Quote: | 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.
|
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 |
|
| Back to top |
|
|
CBFalconer
Guest
|
| Posted:
Fri Jan 28, 2005 5:02 am Post subject:
Re: Relocating application architecture and compiler support |
|
|
Anne & Lynn Wheeler wrote:
| Quote: |
.... snip ...
what i remember from mft/mvt days was that there were (initially?)
two, 2k transient svc areas. part of the issue was that the loader
wasn't involved in reading code into the transient area ... so
there wasn't any ability to perform swizzling operation on any
(relocatable) address constants.
|
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
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson |
|
| Back to top |
|
|
Guest
|
| Posted:
Fri Jan 28, 2005 6:27 pm Post subject:
Re: Relocating application architecture and compiler support |
|
|
In article <41f948f4$1@ibixwebf.ibi.com>,
Edward Wolfgram <Not_Edward_Wolfgram@notiwaysoftware.com> wrote:
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.
| Quote: |
jmfbahciv@aol.com wrote:
In article <41f6b179$1@ibixwebf.ibi.com>,
Edward Wolfgram <Not_Edward_Wolfgram@notiwaysoftware.com> wrote:
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.
Execution of what? An instruction, sure. But not a program!!
..
..
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.
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.
But I don't see any value to the level of relocateabiltiy you are
discussing.
There is lots of value. You guys seem to be confusing OS
execution, user program execution and instruction execution.
/BAH
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.
|
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.
| Quote: | ..Thus, at an
interruption, we can swap a user's context (program and data) at will to
another location in memory.
|
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 :-).
| Quote: | ..Relocation of just the program is not
difficult- just make it reentrant without adcons. But the data, to be
relocateable, also cannot contain addresses.
|
It can't contain absolute addresses without special handling,
where special only means very careful handling.
| Quote: |
But perhaps I'm confused, in which case please elaborate.
|
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. |
|
| Back to top |
|
|
Guest
|
| Posted:
Fri Jan 28, 2005 8:53 pm Post subject:
Re: Relocating application architecture and compiler support |
|
|
In article <41FA5EAB.6BE2081E@yahoo.com>,
CBFalconer <cbfalconer@yahoo.com> wrote:
| Quote: | jmfbahciv@aol.com wrote:
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.
This is all OT on comp.arch.embedded. Please set followups on any
further entries in this thread to eliminate c.a.e.
And the heavens forbid that people who only read c.a.e. |
find out about problems they may have to think about
some time.
/BAH
Subtract a hundred and four for e-mail. |
|
| Back to top |
|
|
CBFalconer
Guest
|
| Posted:
Fri Jan 28, 2005 9:36 pm Post subject:
Re: Relocating application architecture and compiler support |
|
|
jmfbahciv@aol.com wrote:
| Quote: |
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.
|
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
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson |
|
| Back to top |
|
|
Stephen Fuld
Guest
|
| Posted:
Fri Jan 28, 2005 11:09 pm Post subject:
Re: Relocating application architecture and compiler support |
|
|
<jmfbahciv@aol.com> wrote in message news:KtudnRP6wN8T1WfcRVn-sQ@rcn.net...
| Quote: | In article <41f948f4$1@ibixwebf.ibi.com>,
Edward Wolfgram <Not_Edward_Wolfgram@notiwaysoftware.com> wrote:
|
snip
| Quote: | ..Thus, at an
interruption, we can swap a user's context (program and data) at will to
another location in memory.
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 :-).
|
Of course. :-) Actually, it is quite frequent. Consider a time sharing
system where the user program does a request for input from the human at the
terminal. There is an interrupt of the user program from the kernel
request, and it makes sense to swap the program out for what is probably at
least seconds of user think time if there are other user program waiting to
gain access to memory. When the human responds and it is time to swap the
program back in, you don't want to be constrained to swap it in at the same
physical location from where it was swapped out.
--
- Stephen Fuld
e-mail address disguised to prevent spam |
|
| Back to top |
|
|
CBFalconer
Guest
|
| Posted:
Sat Jan 29, 2005 12:30 am Post subject:
Re: Relocating application architecture and compiler support |
|
|
jmfbahciv@aol.com wrote:
| Quote: | CBFalconer <cbfalconer@yahoo.com> wrote:
jmfbahciv@aol.com wrote:
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.
This is all OT on comp.arch.embedded. Please set followups on any
further entries in this thread to eliminate c.a.e.
And the heavens forbid that people who only read c.a.e. find out
about problems they may have to think about some time.
|
People who program your microwave, or even your famous RFI
generating stove, are not likely to be worried about dynamically
relocatable code on system 360, or even on a PDP10. They are
worried about where to get a ten cent chip to handle talking
Barbies, etc.
--
"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
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson |
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted:
Sat Jan 29, 2005 12:58 am Post subject:
Re: Relocating application architecture and compiler support |
|
|
In article <41FA8EFF.1B63B6B2@yahoo.com>,
CBFalconer <cbfalconer@worldnet.att.net> wrote:
| Quote: | jmfbahciv@aol.com wrote:
CBFalconer <cbfalconer@yahoo.com> wrote:
jmfbahciv@aol.com wrote:
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.
This is all OT on comp.arch.embedded. Please set followups on any
further entries in this thread to eliminate c.a.e.
And the heavens forbid that people who only read c.a.e. find out
about problems they may have to think about some time.
People who program your microwave, or even your famous RFI
generating stove, are not likely to be worried about dynamically
relocatable code on system 360, or even on a PDP10. They are
worried about where to get a ten cent chip to handle talking
Barbies, etc.
|
Try reading what was posted again, carefully. Then think about it.
In particular, contemplate:
1) Not everyone writing embedded codes is writing joke ones;
some people are doing heavyweight tasks, like controlling aircraft
or chemical plants.
2) There is an increasing trend to use general purpose hardware
and software for embedded work, so knowing about goes on there is a
potential advantage.
3) The techniques for dynamic relocation are quite important for
high-reliability codes, where you may want to move running code from
a failing CPU to a backup one.
Regards,
Nick Maclaren. |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in