On 22/12/2010 09:27 PM, Darren New wrote:

> Sort of the same way that when a process in UNIX exits, there's a list
> of things the kernel cleans up for it on its way out.

I didn't know it actually did that. I thought that (for example) if a 
Unix process exits without freeing the memory it allocated, that memory 
remains allocated forever. (Presumably it gets pages out to disk fairly 
soon, but even so...)

>> That sounds moderately mental. I'd hate to think what happens if you
>> get the microcode wrong...
>
> The same as if you get any other program wrong. What do you mean? It's
> probably far easier than writing a modern bytecode interpreter like the
> JVM.

I was thinking more that if you get the microcode right, you might 
physically fry the processor.

>> Well, to some extent there /is/. By definition, an application is
>> something that solves a real-world problem, and an OS is something
>> that provides services to applications.
>
> Where do you draw the distinction, if there's exactly one application
> running on the custom OS?

I suppose to some extent it's a bit arbitrary. But if you have, say, a 
library who's only purpose is to take graphics requests and poke the 
necessary hardware registers to make pixels change colour, you could 
call that part of an OS.

The "first" OS was of course the Disk Operating System, remember. ;-)

> I used to use an HP mainframe that was incapable of running C, because
> it was a segmented chip. It was really old, but it would be ideal for
> running an OO language nowadays, because you had tons of segments
> available, etc. Basically, pointers pointed to segments, not bytes, so
> it was in hindsight a very OO kind of architecture.

I'm not sure I see how.

> The Burroughs B series had typed machine code. Each memory address also
> had tag bits saying what type was stored there, so the machine code just
> had an "add" instruction, not an "add integers" or "add floats". The
> operands said what the type was. And array accesses had to go through an
> array pointer, which included the bounds of the array. Again, another
> machine you couldn't run C on.

That sounds much more interesting.

>> OK, now I must know... WTF is this "memmap" that I keep hearing about?
>
> http://lmgtfy.com/?q=what+is+memmap

I'm not sure I completely understand.

So, a memory-mapped file is a region of virtual memory which contains 
the same data as a file on disk? And when you access anything in that 
region, the necessary pages are read from disk? (And, presumably, saved 
back to that file rather than being copied to swap when physical memory 
is required.)

So... how do you change the size of the file then?

Post a reply to this message