Re: Machine-Level Assembly Language

Allodoxaphobia <bit-bucket@[EMAIL PROTECTED]
> writes:
> When you get to "Assembly Language", you require some sort of compiler 
> to decode/encode the almost-english-like instruction mnemonics into the 
> actual binary encoding usable by the target machine.
>
> Then there's the topic of Relocatability.........

don't get me started ... it was one of the severe problems ...  the
os/360 relocatable address adcons ... lots of past posts on the severe
problems it gave me 
http://www.garlic.com/~lynn/subtopic.html#adcons

the science center in the mid-60s
http://www.garlic.com/~lynn/subtopic.html#545tech

along with starting out with doing the cp40 virtual machine
implementation (also doing hardware modifications to 360/40 for virtual
memory sup****t), also did cms (started out as cambridge monitor system,
was later renamed to converstation monitor system).

cms made extensively use of os/360 language applications (assemblers,
compilers, etc) with emulation of the required os/360 facilities. this
included program link/loader having to sup****t the intermediate
os/360 TXT conventions ... old post with "RLD" format:
http://www.garlic.com/~lynn/2002o.html#26
Relocation, was Re: Early
computer games

starting on cp67 (the science center had morphed cp40 to cp67 when
360/67 with standard virtual memory hardware became available), i had
implementated page-mapped filesystem sup****t for cms with a lot of
features for mapping executable files (from the filesystem) into virtual
memory. some old email referencing migrating work from cp67 to vm370
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

while the page-mapped filesystem stuff never ****pped in product ... it
was extensively used in internal distributions ...  recent reference
http://www.garlic.com/~lynn/2008g.html#48
How did third-party software
companies deal with unbundling being sprung on them?

a small subset of the csc/vm sup****t for mapping of objects to virtual
memory was ****pped in vm370 release three as DCSS. This somewhat
happened because the demise of future system
http://www.garlic.com/~lynn/subtopic.html#futuresys

and the resulting mad rush to get stuff back into the 370 product
pipeline ... created op****tunity for picking up and ****pping a lot of
stuff that I had been doing (all thru the future system period) ...
see the above referenced post regarding unbundling.

part of the issue was the original/basic sup****t permitted a page-mapped
filesystem object to be mapped to an arbitrary virtual memory address as
well the same virtual memory object to be mapped to multiple different
virtual address spaces (as shared object) ... and a shared object wasn't
required to appear at the same virtual address in different virtual
address spaces.

the os/360 TXT deck convention for RLD processing ... was that when the
executable object is fetched and mapped to address space ... all the RLD
address constants have to be swizzled to correspond to the loaded
address. These has very adverse effects in a virtual memory environment.
First ... all the virtual pages containing relocatable address
constants, were being prefetched and modified before program execution
could begin (forcing changed status on the page). Second ... once the
relocatable address constants were swizzled to correspond with executing
virtual address ... it was pinned to that address and wouldn't work at
different addresses (eliminating the feasability of having the same
virtual executable object appearing simultaneously at arbitrary
different virtual addresses in different virtual address spaces).

At least this was one area where tss/360 did get it right (and some
number of other operating systems specifically designed for virtual
memory environment) ... which had executable object convention that
allowed for it to be page-mapped with-out requiring all the relocatable
address constants in arbitrary virtual pages to be modified ... as well
as allowing for shared executable image to appear at arbitrary virtual
addresses in different virtual address spaces.

For all the executable images that I would allow to appear at arbitrary
virtual addresses ... w/o pre-swizzling all the relocatable address
constants ... i had to go thru the source and eliminate all such
relocatable address constants. This was complicated by CMS having a
kernel API SVC202 interface that had a convention with a relocatable
address constant (frequently "*+4") following the SVC instruction.
http://www.garlic.com/~lynn/2004f.html#23
command line switches [Re:
[REALLY OT!] Overuse of symbolic