strong/weak typing and pointers

[Alex Martelli]

Steven Bethard <steven.bethard at gmail.com> wrote:

> Alex Martelli <aleaxit <at> yahoo.com> writes:
> >
> > Steven Bethard <steven.bethard <at> gmail.com> wrote:
> > 
> > > On the other hand, I haven't really seen any good
> > > cases for wanting weak-typing in a statically-typed language either.
> > 
> > How would an operating system's filesystems store arbitrary sequences of
> > bytes (which might be floats, int, whatever -- only the application
> > knows) into disk pages (blocks of, say , 4096 bytes each) otherwise?
> 
> Valid point of course.  But the OS doesn't really take advantage of
> weak-typing here if it takes an arbitrary sequence of bytes and stores an
> arbitrary sequence of bytes.  I haven't written much OS code (just a
> prototype system back in undergrad), but I never cast one type of struct
> to another -- to and from void*, but never between types.

Is the OS going to be able to read something from disk and *USE* it?

> Of course, I'm sure there're are a number of good reasons to do so -- my
> claim was only that I hadn't seen them.  I'd be grateful if you could
> point me to an example.  =)

Suppose for example that you would like your OS to be able to load
executable code from disk into memory and execute it.  Suppose you would
like it to be able to read some configuration parameters from disk and
set its own internal data structures accordingly.  At one level, as it
goes to disk or comes back from there, you have arrays of bytes.  But in
memory, you want functions that can be called appropriately (a device
driver residing in a module) or data structures which, differently from
an array of byte, DO have structure -- for example, a partition table
for a disk, with information to specific filesystem drivers as to what
partition is to be treated in what way.

I don't understand how you can have failed to see a zillion more
examples of operating systems actively _using_ data read from disk,
since it's such a widespread phenomenon nowadays.

 
> > Even if you design a new OS based on a filesystem whose files are all
> > "strongly typed"
> 
> You really do think I'm satan, don't you? ;)

I'm old enough to have fought my way through filesystems more strongly
typed than plain streams of bytes, sure -- Unix was already around but
not all-pervasive yet.  I remember peripherals which wanted streams, but
streams of _SIX_-bit "bytes" -- so you had to have somewhere a pack-and-
unpack routine that could take (e.g.) a block of 48 8-bit bytes and
reinterpret it as a block of 64 6-bit bytes, or viceversa.  I hope there
aren't any more of _those_ around -- but in exchange we have, for
example, pervasive issues of unicode vs byte streams and encodings.

It's not just files, either.  We have memory sliced up into pages, and a
page is, say, a well defined object of 4096 bytes.  But we want to be
able to store all different kinds of stuff into those bytes - we HAVE
to, in fact, because that is all the memory we have... all pages...

If your point is that all you need is, not to "overlay" different
structures onto the same address, but "just" to overlay "look at this as
raw bytes" upon any structure and viceversa -- can't you see you're
doing exactly the same thing with just one conceptual extra step?
Instead of
    struct foo* p = ...;
    struct bar* q = (struct bar*) p;
you're thinking
    struct foo* p = ...;
    void *v = (void *) p;
    struct bar* q = (struct bar*) v;
but it's just the same thing, and v can be optimized away.

Above the lowest levels, you can get away with (at least conceptually)
copying stuff in order to be able to reinterpret bits, as you can do in
Python with x = struct.unpack(f1, struct.pack(f2, y)) -- you can do
plenty of bit-level reinterpretation but not *in-place*, only via
copying.  But you can't generally afford that luxury when you dig deep
enough -- copying bits around when you only need to reinterpret them is
paying a real cost in memory and CPU and bus bandwidth, after all.  It
doesn't have to be OS-level: any virtual machine has similar issues.
So, look at the CPython interpreter sources, for example... what
performance price would it have to pay if it couldn't cast pointers but
rather had to copy bits around each time it now does a cast?


Alex