Re: Shared libraries and modules

In article <lFz*FnXqs@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Theo Markettos <theom+news@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Keith Hopper <kh@xxxxxxxxxxxxx> wrote:
May I be permitted to turn the clock back about thirty years to
another computer architecture which (in my opinion) should have been built
on so that we would not have the rather woolly divisions between OS,
drivers, modules and libraries that pervades the computer world today.

I do agree we've lost quite a bit from the homogenising of architectures,
which was why my comments only referred to Windows and Unix: I haven't had
enough low-level experience in other systems with shared libraries to
comment (and indeed most other platforms I can think of that have seen
recent development are slightly moribund: classic MacOS, OS/2, Amiga, BeOS,
VMS. Possibly S/390 is going strong, but I have no experience).
Comparative Architectures isn't as interesting as it once was (in the OS
sense, at least - the hardware has got more interesting).

I refer to the now extinct Burroughs 5500/6500/7500/8500 series of
machines which had hardware tags on each and every machine word. Among
other things there were tagh values for code, for data, for system code,
for what were called intrinsics, etc. Certain privileges were needed to
access the different kinds of memory. The actual OS kernel was quite small
although the OS itself stood about desk height (from the ground) on
lineflow paper.

The tags are useful, and are coming back into fashion for security or
parallel computation. Sometimes these days they're on a per-page basis
rather than per-word.

[snip]

One of the things which seems to me to be missing from OS program
support facilities is hardware help for generic class libraries - which are
of great interest to those using high-level programming languages. One does
not want to have the code, say, for a "stack of widgets" being different
from that for a "stack of butterflies" - in other words a stack is just a
stack. So far as I am aware, there is at the present time no way of
'changing' the object for the implementation code of a container of this
kind at run-time. If a program has 27 different kinds of stack then it
still needs 27 chunks of implementation code - dependent on the 'kind' of
content - which is potentially wide ranging.

I don't quite understand this. There are two basic implementations of
stacks:
'A stack of 32 bit words'
'A stack of pointers'

Ooohh! No! What about a stack of 4-bit objects or 8-bit ones or
80-bit ones??? Think of the inefficiencies of using 32-bit instructions
willy-nilly when handling UTF-8 or UTF-16 or double length floats or many
enumerations - very few of which exceed 8-bit spaces.


Anyway, people don't program in assembler these days. Typically the
compiler will handle this just fine - if it generates 27 chunks of code then
we don't care as long as they're not too big. If they run faster that way,
so much the better. The lesson we learnt with RISC was that if you add
complex architectural features compilers couldn't make use of them, so why
bother, especially if they increase the cycle time?

I'm perhaps old-fashioned, but I know that many architectures are more
efficient when using narrow octets, hextets, than with register wide
manipulations and shifts, etc. I'v always been concerned to minimise times
AND space when writing a code generator.

These sorting examples are trivial because they're not going to take
megabytes of code. Can you cite any examples where large code chunks would
be reusable by these class library techniques? I can't think of any.

Whatever work is done to improve code re-use should, for me, make use
of hardware support (however that may be achieved) and support five memory
spaces - RTE, program code, libraries, generic classes and data.

In Unix we have three:
Text: code and read-only data (eg const char *s="Hello world"; )
Data: initialised writable data (eg static int f=123; )
BSS: uninitialised data (eg static int f; )

There's no particular distinction between program and libraries. Indeed, if
we want to run a program more than once we want to share the program just as
much as we want to share the libraries. All code is marked read-only, so
it's not possible for instances to modify themselves.

I don't really understand why the runtime is special - isn't it just another
library?

Very definitely not! If a program in a class-based language wished to
have a garbage collecting memory management facility then this could
seriously affect the whole machine memory managemtne if it isn't done under
the OS (so to speak). What about languages using exception mechanisms - I
am horrified at the way that all fomrs of asynchronous transfer of control
are around so that no program - unless it implements its own exception
mechanism can treat all of them in the same way - unless this is done under
the OS (again so to speak), then it becomes a bolt-on obfuscation of
implementation code which makes a nonsense of code efficiency.

What about threading/processes, etc. Various models of multi-threading
exist and, so far as I am aware, each one seems to be bolted onto the
outside of the OS.

Dynamic code generation requires all sorts of convolutions to
interface it to the OS properly if you don't have a low-level interface to
the 'exec'(say) loader.

It is my contention that these sort of things are - if efficiently
implemented the micro-kernel of an OS - everything else is dynamically
loadable 'modules' and 'libraries. We really do need a new approach to
object OS architecture to improve efficiencies and permit any programming
language to define its own RTE to interface directlyt with the
micro-kernel.

What about distributed programs which really need to be below the IP
level so far as comms and interrupts, etc are concerned?

Frankly, I'm not interested in what commercial organisation do or wish
to do - only in getting it right - whatever that may mean for any
individual language designer.

Keith

--
Sky Development
.