Skip to main content
Retrocomputing

Return to Answer

added 4 characters in body
Source Link
rcgldr
rcgldr
  • 745
  • 3
  • 9

Although not the earliest example, in 1973, IBM released APL.SV (A Programming Language | Shared Variables). Variables (of any number of dimensions) could be shared between instances (effectively threads) of APL programs running on different terminals. Not mentioned in the wiki article linked to below is that APL.SV ran in supervisor mode, so there was no hardware based memory mapping or protection, just software checks like out of bounds indexing.

It was also possible for APL.SV programs to use file based synchronization and data transfer to work with batch programs that were running at the same time.

There were various ways to "glitch" array variables so that one array included the control structure for another array, allowing modification of array size to be set to double physical memory size. Each instance of an APL thread started with a standard IBM save area, where word 13 (corresponding to register 13) contained the absolute address of the save area. This led allowed simple math to convert translate an absolute address into a save area relative address, allowing APL.SV programs to modifyread|write absolute addresses in memory.

https://en.wikipedia.org/wiki/APL_(programming_language)#Commercial_availability

Although not the earliest example, in 1973, IBM released APL.SV (A Programming Language | Shared Variables). Variables (of any number of dimensions) could be shared between instances (effectively threads) of APL programs running on different terminals. Not mentioned in the wiki article linked to below is that APL.SV ran in supervisor mode, so there was no hardware based memory mapping or protection, just software checks like out of bounds indexing.

It was also possible for APL.SV programs to use file based synchronization and data transfer to work with batch programs that were running at the same time.

There were various ways to "glitch" array variables so that one array included the control structure for another array, allowing modification of array size to be set to double physical memory size. Each instance of an APL thread started with a standard IBM save area, where word 13 (corresponding to register 13) contained the absolute address of the save area. This led allowed simple math to convert translate an absolute address into a save area relative address, allowing APL.SV programs to modify absolute addresses in memory.

https://en.wikipedia.org/wiki/APL_(programming_language)#Commercial_availability

Although not the earliest example, in 1973, IBM released APL.SV (A Programming Language | Shared Variables). Variables (of any number of dimensions) could be shared between instances (effectively threads) of APL programs running on different terminals. Not mentioned in the wiki article linked to below is that APL.SV ran in supervisor mode, so there was no hardware based memory mapping or protection, just software checks like out of bounds indexing.

It was also possible for APL.SV programs to use file based synchronization and data transfer to work with batch programs that were running at the same time.

There were various ways to "glitch" array variables so that one array included the control structure for another array, allowing modification of array size to be set to double physical memory size. Each instance of an APL thread started with a standard IBM save area, where word 13 (corresponding to register 13) contained the absolute address of the save area. This allowed simple math to convert translate an absolute address into a save area relative address, allowing APL.SV programs to read|write absolute addresses in memory.

https://en.wikipedia.org/wiki/APL_(programming_language)#Commercial_availability

Source Link
rcgldr
rcgldr
  • 745
  • 3
  • 9

Although not the earliest example, in 1973, IBM released APL.SV (A Programming Language | Shared Variables). Variables (of any number of dimensions) could be shared between instances (effectively threads) of APL programs running on different terminals. Not mentioned in the wiki article linked to below is that APL.SV ran in supervisor mode, so there was no hardware based memory mapping or protection, just software checks like out of bounds indexing.

It was also possible for APL.SV programs to use file based synchronization and data transfer to work with batch programs that were running at the same time.

There were various ways to "glitch" array variables so that one array included the control structure for another array, allowing modification of array size to be set to double physical memory size. Each instance of an APL thread started with a standard IBM save area, where word 13 (corresponding to register 13) contained the absolute address of the save area. This led allowed simple math to convert translate an absolute address into a save area relative address, allowing APL.SV programs to modify absolute addresses in memory.

https://en.wikipedia.org/wiki/APL_(programming_language)#Commercial_availability