🚀 go-pugleaf

Jon Elson <el...@pico-systems.com> writes:
> The 360 had register to register operations, indexed storage to register, 
> and storage to storage.  The indexed storage form had a base register which 
> pointed to the beginning of your memory partition, an index register, and a 
> 12-bit offset in the instruction field.  This was VERY convenient for data 
> structure operations (like the C construct struct).  The base register made 
> it possible to have fully relocatable object programs, but once a program 
> began to execute, it would save physical addresses (subroutine return 
> locations and pointers to data) and so could not be moved to a different 
> place in memory.

and DOS/OS/360 executables had adcon convention that were swizzled to
fixed address when loaded into memory. this created all sorts of
problems when moving from real storage to segmented virtual
memory. TSS/360 (360/67) addressed this problem so there wasn't fixed
addresses somewhat randomly distributed thru executable i.e. resulted in
changed pages that had to be paged out to new locations and no longer
the same was the original executable image ... and also resulted in not
being able to share same executable image in different virtual address
spaces (at arbitrary different virtual address location).

I've complained periodically about the address constant convention when
I added virtual page-mapped filesystem support to cp67/cms (and then
migrated to vm370/cms). CMS had a bunch of native applications ... but
also made heavy use of lots of os/360 applications (including the
assemblers and compilers) with os/360 simulation ... that heavily used
the adcon executable convention.

past posts complaining about the adcon problem
http://www.garlic.com/~lynn/submain.html#adcon
past posts mentioning doing CMS page-mapped filesystem implementation
http://www.garlic.com/~lynn/submain.html#mmap

-- 
virtualization experience starting Jan1968, online at home since Mar1970