Protected memory and Forth 
Author Message
 Protected memory and Forth

I just went over Nelson Buck's ruminations on a Forth OS from 1995 or so
on his/MDFIG's webpage. It's interesting in that he was talking about a
level then that Forth hasn't reached yet to my knowledge, and that there
seems to be a bit of consensus in the Forth world that a Forth OS should
have protected memory but not memory virtualized on mass store. This is an
elusive subject. I just let a little flamefest on a linux newgroup die out
after asking the Linux followers what VM is worth. Unix people of course
feel the unix way is unimproveable, and that VM is well worth the cost.
There's a terminology problem also, reminiscent of the various meanings of
"compiler".

How, exactly, do you do hardware-protected memory without also doing
pretend-memory-on-disk? Do you use pages, or segments? On what hardware?
There's virtual memory, and there's virtual addresses. Virtual addresses
may be restricted to offsets within real memory, and that can be done
using pages or segments. Memory protection can be implemented with
neither.

Let's say we're talking about the 386+, and that we definitely want
hardware-protected-memory processes. Even there, I suspect "sequestered
memory" or similar is a better term. From the point of view of the
process, it is protected by the fact that other processes are also
sequestered like it is, and thus it's sequestered-ness is what is most
visible to it.

The 386+ can do sequestered memory in conjunction with the GDT, Global
Descriptor Table, with or without address virtualization. I think. Each
GDT enty, i.e. each defined segment in the system, has bounds specified in
the GDT entry, and I believe the start address for the segment further
specifies how the addresses in the segment are to be virtualized. Yes? So,
a loader could be devised to load programs at real addresses but to set
the bounds of the segment/process accordingly at load time. That would be
protected-not-virtual-at-all. That would however be a fancy loader, rather
like a runtime linker.

With a single address offset for an entire process or segment, you have
segment virtual addresses. This I believe simplifies the loader, and
runtime cost on 386+ should still be zero. The load time cost is that
memory allocation is rustic. You need a contiguous real space for a
process.

With pages, allocating the memory for a new process is trivial, but I
think even without swap you have some runtime cost for address
computation.

In forth you may have other options. A new process can be compiled at
load-time. This may simplify the simplest case, sequestered physical
non-virtualized spaces. It may also have interesting effects on the other
cases, such as compiling to pages.  

This is what seems to be just over the horizon for Forth. Take your picks.

Rick Hohensee
                                                www.clienux.com



Fri, 06 Feb 2004 17:18:04 GMT  
 Protected memory and Forth

Quote:
> How, exactly, do you do hardware-protected memory without also doing
> pretend-memory-on-disk? Do you use pages, or segments? On what hardware?
> There's virtual memory, and there's virtual addresses.

You're right, the term "virtual" is confusingly overloaded in these
discussions.

A memory management unit (MMU) creates virtual, or "logical", address
spaces, and maps them, page by page (or segment by segment), into the
physical memory that is present on the machine. Usually, each process
running on the machine gets one of these logical address spaces to run
in, and it basically starts at address zero and goes as high as needed.

This has all kinds of advantages, even if you ignore the ability to swap
pages to disk (virtual memory). The first is protection: if no mapping
to a particular physical page exists in the current process's logical
address space, then that process cannot affect that page in any way.

The second is the ease of dynamically allocating physical memory to
processes: pages that are contiguous in the logical address space do not
need to be contiguous in physical memory. One example of this is managing
stack space. Suppose you allocate 16 4KB pages (64KB) initially for a
process's stack, but it turns out to be a deeply recursive process that
needs more. As soon as it touches the first location outside the allocated
area, an exception will occur and the underlying handler will have the
option of assigning additional physical memory to that process for its
stack. When the handler returns, the process will continue as though it
had had that memory all along. "Heap" or "dictionary" space can be grown
as needed in the same way.

Memory can be shared by having two or more logical address spaces map some
of their pages to the same set of physical pages. You can even set this up
so that only one process at a time has "write" permission for the pages.

Finally, you can do virtual memory if you want. All this means is that
there's an entry in the logical address map for a page, but there's a
"not present" flag set and a disk address is stored in the map instead
of a physical memory address. When the process touches the page, it gets
suspended until such time as the I/O can be done to bring the page into
memory. Then the mapping is updated to "present" and the new physical
address of the page, and then the process can be resumed.

-- Dave Tweed



Fri, 06 Feb 2004 19:59:46 GMT  
 Protected memory and Forth

Quote:

>> How, exactly, do you do hardware-protected memory without also doing
>> pretend-memory-on-disk? Do you use pages, or segments? On what hardware?
>> There's virtual memory, and there's virtual addresses.

>You're right, the term "virtual" is confusingly overloaded in these
>discussions.

Yes, "virtual memory" tends to devolve to "what unix does" (or later
versions of Windows), which is a large superset of virtual memory. The
Forth community is now at a point where what should be done might bear a
reassessment. I personally tend to mean "fake RAM on disk" when I say
"virtual memory". "Virtual addresses" are entirely separate, as are
page/segment choices. I think. On 386+.

Quote:

>A memory management unit (MMU) creates virtual, or "logical", address
>spaces, and maps them, page by page (or segment by segment), into the
>physical memory that is present on the machine. Usually, each process
>running on the machine gets one of these logical address spaces to run
>in, and it basically starts at address zero and goes as high as needed.

>This has all kinds of advantages, even if you ignore the ability to swap
>pages to disk (virtual memory). The first is protection: if no mapping
>to a particular physical page exists in the current process's logical
>address space, then that process cannot affect that page in any way.

I believe on 386+ protection is possible entirely with physical addresses,
but I'm not sure. I also believe the 386+ may be fairly unique in that
respect. "The Indispensible PC Hardware Book" notes with some due awe that
the support target of the 386 was Multics, which is a monster. I'm not
fond of x86 generally, and have nothing but disdain for the 8086, but the
transition from there to the 386 is astounding.

Quote:

>The second is the ease of dynamically allocating physical memory to
>processes: pages that are contiguous in the logical address space do not
>need to be contiguous in physical memory. One example of this is managing
>stack space. Suppose you allocate 16 4KB pages (64KB) initially for a
>process's stack, but it turns out to be a deeply recursive process that
>needs more. As soon as it touches the first location outside the allocated
>area, an exception will occur and the underlying handler will have the
>option of assigning additional physical memory to that process for its
>stack. When the handler returns, the process will continue as though it
>had had that memory all along. "Heap" or "dictionary" space can be grown
>as needed in the same way.

Let's not be hasty. Pages also aid static memory allocation, i.e.
process-spawn-time, which is more compelling to me. Fragmented RAM is not
a problem. BUT, what's the run-time cost? Nobody that will stoop to talk
to me on the Linux groups really had a cogent answer. This is because unix
is a big information slush-fund, and things like that are quite difficult
to know.

Quote:
>Memory can be shared by having two or more logical address spaces map some
>of their pages to the same set of physical pages. You can even set this up
>so that only one process at a time has "write" permission for the pages.

>Finally, you can do virtual memory if you want. All this means is that

I think you already did in "The second is ...". If you hadn't mentioned a
growing stack you might have been talking about a copy-on-write scheme for
initial allocation, which is perhaps a form of semi-virtual memory.

Quote:
>there's an entry in the logical address map for a page, but there's a
>"not present" flag set and a disk address is stored in the map instead
>of a physical memory address. When the process touches the page, it gets
>suspended until such time as the I/O can be done to bring the page into
>memory. Then the mapping is updated to "present" and the new physical
>address of the page, and then the process can be resumed.

So what are the primitives that lead to a Forth-like factoring of these
facilities? A bootable Forth can be extended for a lot of this stuff. The
interrupt handlers themselves aren't Forth per se, but all the various
signal handler installers and so on are predicted by CATCH and THROW to
some extent.

Rick Hohensee
                                                www.clienux.com

Quote:
>-- Dave Tweed



Sat, 07 Feb 2004 01:01:28 GMT  
 Protected memory and Forth


Quote:
> I just went over Nelson Buck's ruminations on a Forth OS from 1995 or so
> on his/MDFIG's webpage. It's interesting in that he was talking about a
> level then that Forth hasn't reached yet to my knowledge, and that there
> seems to be a bit of consensus in the Forth world that a Forth OS should
> have protected memory but not memory virtualized on mass store. This is an
> elusive subject. I just let a little flamefest on a linux newgroup die out
> after asking the Linux followers what VM is worth. Unix people of course
> feel the unix way is unimproveable, and that VM is well worth the cost.
> There's a terminology problem also, reminiscent of the various meanings of
> "compiler".

> How, exactly, do you do hardware-protected memory without also doing
> pretend-memory-on-disk? Do you use pages, or segments? On what hardware?
> There's virtual memory, and there's virtual addresses. Virtual addresses
> may be restricted to offsets within real memory, and that can be done
> using pages or segments. Memory protection can be implemented with
> neither.

> Let's say we're talking about the 386+, and that we definitely want
> hardware-protected-memory processes. Even there, I suspect "sequestered
> memory" or similar is a better term. From the point of view of the
> process, it is protected by the fact that other processes are also
> sequestered like it is, and thus it's sequestered-ness is what is most
> visible to it.

> The 386+ can do sequestered memory in conjunction with the GDT, Global
> Descriptor Table, with or without address virtualization. I think. Each
> GDT enty, i.e. each defined segment in the system, has bounds specified in
> the GDT entry, and I believe the start address for the segment further
> specifies how the addresses in the segment are to be virtualized. Yes? So,
> a loader could be devised to load programs at real addresses but to set
> the bounds of the segment/process accordingly at load time. That would be
> protected-not-virtual-at-all. That would however be a fancy loader, rather
> like a runtime linker.

> With a single address offset for an entire process or segment, you have
> segment virtual addresses. This I believe simplifies the loader, and
> runtime cost on 386+ should still be zero. The load time cost is that
> memory allocation is rustic. You need a contiguous real space for a
> process.

> With pages, allocating the memory for a new process is trivial, but I
> think even without swap you have some runtime cost for address
> computation.

    At least on IA32, you get virtualization for free.  What you pay for, is
swapping.  There's no advantage to having protected memory without
virtualization.

--

-GJC

-Abolish Public Schools.



Sat, 07 Feb 2004 04:25:42 GMT  
 Protected memory and Forth

Quote:
> I believe on 386+ protection is possible entirely with physical addresses,
> but I'm not sure. I also believe the 386+ may be fairly unique in that
> respect.

Without looking it up, I would guess that it's done by having a single
logical address space that's mapped 1:1 to physical memory, and then
turning off permissions on the pages you want to protect. Perhaps the
386 MMU has a special "map 1:1" mode that bypasses the need to set up
all of the page tables explicitly.

Quote:
> Let's not be hasty. Pages also aid static memory allocation, i.e.
> process-spawn-time, which is more compelling to me. Fragmented RAM is not
> a problem.

I guess it depends on whether you have frequent spawnings of short-lived
processes, or longer-lived processes that have memory requirements that
vary over time. The MMU is a definite plus in both cases.

Quote:
> BUT, what's the run-time cost?

Tiny. There's the overhead of setting up the page tables at process-spawn
time. Once that's done, it's usually just a matter of changing one register
and flushing the TLB (translation lookaside buffer) at process-switch time.
Within each process, there's a small amount of overhead on the first access
to each page as the MMU hardware "walks the tables" to load the TLB entry.
The only other overhead occurs whenever the exception handler gets called,
and by being generous with your initial allocations, you can minimize that.

Quote:
> I think you already did in "The second is ...". If you hadn't mentioned a
> growing stack you might have been talking about a copy-on-write scheme for
> initial allocation, which is perhaps a form of semi-virtual memory.

Not really. Copy-on-write is an optimization related to the fork-then-exec
model of spawning found on Unix systems. A fork() creates a second process
running in an identical address space as the first. This can be done by
setting up a second logical address space that points to all of the same
physical pages as the first, and then marking *all* pages read-only in
*both* logical address spaces. If either process attempts a write, only
then does the exception handler create a second physical copy of the page
and mark it writable. By deferring the copying of the data this way, it can
be skipped altogether if the second process immediately does an exec(), as
this creates a whole new logical address space anyway.

I didn't mention copy-on-write in the first go-around because I didn't
think it was relevant to the way multiprocessing is typically done in
Forth systems.

Quote:
> So what are the primitives that lead to a Forth-like factoring of these
> facilities?

I'm afraid I can't help you there. Most of my Forth hacking was done 15-20
years ago, before I had access to hardware with MMUs. I haven't really kept
up with the state of the art since then, although I continue to lurk here.

I could speculate wildly if you like... :-)

-- Dave Tweed



Sat, 07 Feb 2004 04:28:05 GMT  
 Protected memory and Forth

Quote:

> There's no advantage to having protected memory without virtualization.

That's not really true. Even if the only hardware facility available was
the ability to turn off write access on a page-by-page basis, this would
be valuable in a multitasking embedded system to isolate a crash to a single
task.

Granted, on non-embedded general purpose multitasking operating systems,
the problems of managing memory without virtualization become overwhelming.

-- Dave Tweed



Sat, 07 Feb 2004 04:54:10 GMT  
 Protected memory and Forth


Quote:

> > There's no advantage to having protected memory without virtualization.

> That's not really true. Even if the only hardware facility available was
> the ability to turn off write access on a page-by-page basis, this would
> be valuable in a multitasking embedded system to isolate a crash to a
single
> task.

> Granted, on non-embedded general purpose multitasking operating systems,
> the problems of managing memory without virtualization become

overwhelming.

    My wording was poorly chosen.  I was think only in terms of direct
performance overhead.

--

-GJC

-Abolish Public Schools.



Sat, 07 Feb 2004 05:09:41 GMT  
 Protected memory and Forth

Quote:

>> I believe on 386+ protection is possible entirely with physical addresses,
>> but I'm not sure. I also believe the 386+ may be fairly unique in that
>> respect.

>Without looking it up, I would guess that it's done by having a single
>logical address space that's mapped 1:1 to physical memory, and then
>turning off permissions on the pages you want to protect. Perhaps the
>386 MMU has a special "map 1:1" mode that bypasses the need to set up
>all of the page tables explicitly.

The GDT, Global descriptor table, has the bounds for a segment right
there. That's what protection is based on, those two limits. If they are
set up to physical addresses I think you have non-virtual protection. I'll
go look when I'm done with Usenet.

Quote:

>> Let's not be hasty. Pages also aid static memory allocation, i.e.
>> process-spawn-time, which is more compelling to me. Fragmented RAM is not
>> a problem.

>I guess it depends on whether you have frequent spawnings of short-lived
>processes, or longer-lived processes that have memory requirements that
>vary over time. The MMU is a definite plus in both cases.

>> BUT, what's the run-time cost?

>Tiny. There's the overhead of setting up the page tables at process-spawn
>time. Once that's done, it's usually just a matter of changing one register
>and flushing the TLB (translation lookaside buffer) at process-switch time.
>Within each process, there's a small amount of overhead on the first access
>to each page as the MMU hardware "walks the tables" to load the TLB entry.
>The only other overhead occurs whenever the exception handler gets called,
>and by being generous with your initial allocations, you can minimize that.

OK, so there is some cost to paging. And it's partly proportional to
task-switch frequency. Flushing a TLB is not a two-clock affair, so I
suspect it's quite un-tiny with a tiny timeslice quantum.

- Show quoted text -

Quote:
>> I think you already did in "The second is ...". If you hadn't mentioned a
>> growing stack you might have been talking about a copy-on-write scheme for
>> initial allocation, which is perhaps a form of semi-virtual memory.

>Not really. Copy-on-write is an optimization related to the fork-then-exec
>model of spawning found on Unix systems. A fork() creates a second process
>running in an identical address space as the first. This can be done by
>setting up a second logical address space that points to all of the same
>physical pages as the first, and then marking *all* pages read-only in
>*both* logical address spaces. If either process attempts a write, only
>then does the exception handler create a second physical copy of the page
>and mark it writable. By deferring the copying of the data this way, it can
>be skipped altogether if the second process immediately does an exec(), as
>this creates a whole new logical address space anyway.

>I didn't mention copy-on-write in the first go-around because I didn't
>think it was relevant to the way multiprocessing is typically done in
>Forth systems.

>> So what are the primitives that lead to a Forth-like factoring of these
>> facilities?

>I'm afraid I can't help you there. Most of my Forth hacking was done 15-20
>years ago, before I had access to hardware with MMUs. I haven't really kept
>up with the state of the art since then, although I continue to lurk here.

>I could speculate wildly if you like... :-)

I am in no position to denigrate wild speculation :o)

Rick Hohensee
                                                www.clienux.com

- Show quoted text -

Quote:

>-- Dave Tweed



Sat, 07 Feb 2004 05:59:56 GMT  
 Protected memory and Forth

Quote:




>> > There's no advantage to having protected memory without virtualization.

>> That's not really true. Even if the only hardware facility available was
>> the ability to turn off write access on a page-by-page basis, this would
>> be valuable in a multitasking embedded system to isolate a crash to a
>single
>> task.

>> Granted, on non-embedded general purpose multitasking operating systems,
>> the problems of managing memory without virtualization become
>overwhelming.

>    My wording was poorly chosen.  I was think only in terms of direct
>performance overhead.

It looks to me like maybe virtual address segments might be free, but
paging isn't. On 386+.

Rick Hohensee
                                        www.clienux.com

- Show quoted text -

Quote:
>--

>-GJC

>-Abolish Public Schools.



Sat, 07 Feb 2004 06:01:15 GMT  
 Protected memory and Forth

Quote:
> Flushing a TLB is not a two-clock affair, so I suspect it's quite un-tiny
> with a tiny timeslice quantum.

Actually, flushing a TLB usually *is* instantaneous on most processors.
It's a content-addressable memory, and the additional hardware to clear
all of the "valid" flags in parallel is trivial. Re-loading the entries
for the newly-activated process is what takes some time, but this is
done only as needed. With a tiny timeslice, the process will touch fewer
pages, so this evens out.

Some MMUs store the ASID (logical address space identifier) in the TLB
so that a flush is not required on every process switch.

Only the most bare-bones RISC machines do TLB management (flushing and
table-walking) in software instead of hardware.

Quote:
> I am in no position to denigrate wild speculation :o)

OK, then let me make a few observations.

The ability to spawn new processes and manage the memory for them is
actually rather straightforward. The real key is figuring out exactly
what sort of memory-sharing, interprocess communications and synchro-
nization mechanisms are most appropriate for the types of applications
a multiprocessing Forth would be used for.

(What sort of IPC mechanisms, if any, do Forths for existing
 multiprocessing OSs support? All my Forth experience was on
 single-tasking systems like CP/M and on embedded systems.)

The basic "fork" style of spawning with copy-on-write could actually
work rather well for the basic dictionary-and-two-stacks memory
architecture of Forth, where much of the dictionary (except for embedded
data structures) would remain shared throughout the life of the system.

It might also be useful to have a thread-fork in which the dictionary
is fully shared even for writes, and only the stacks are unique to each
thread.

This is really starting to move into the area of OS design. Things to
think about:
* processes can be spawned; how do they die and/or get killed from
  other processes?
* how is CPU time allocated among processes and/or threads?
  Cooperative? Preemptive? Priorities?
* how much of this is handled by the "kernel" (whatever that is) and
  how much by ordinary processes?

It might be instructive to work this from the other end -- take a
microkernel OS like Minix-VMD and see how much of it you'd want and
how you might implement it in Forth.

If you're really {*filter*}ic, take a look at the design of the Windows
NT kernel. Underneath all of the backwards-compatibility cruft, it
actually implements some interesting virtual machine mechanisms, where
even the memory manager, task switch priority mechanism, and protection
mechanisms are outside the primary kernel. This is probably more extreme
than most people are prepared to deal with. :-)

-- Dave Tweed



Sat, 07 Feb 2004 07:44:27 GMT  
 Protected memory and Forth


Quote:

> If you're really {*filter*}ic, take a look at the design of the Windows
> NT kernel. Underneath all of the backwards-compatibility cruft, it
> actually implements some interesting virtual machine mechanisms, where
> even the memory manager, task switch priority mechanism, and protection
> mechanisms are outside the primary kernel. This is probably more extreme
> than most people are prepared to deal with. :-)

    When you get down to this level, Win32 starts looking like a nice OS.
Microsoft was smart enough to know that they didn't have the expertise to
design the OS they wanted, and hired the people who implemented VMS.

--

-GJC

-Abolish Public Schools.



Sat, 07 Feb 2004 08:53:24 GMT  
 Protected memory and Forth

Quote:

>> Flushing a TLB is not a two-clock affair, so I suspect it's quite un-tiny
>> with a tiny timeslice quantum.

>Actually, flushing a TLB usually *is* instantaneous on most processors.
>It's a content-addressable memory, and the additional hardware to clear
>all of the "valid" flags in parallel is trivial. Re-loading the entries
>for the newly-activated process is what takes some time, but this is
>done only as needed. With a tiny timeslice, the process will touch fewer
>pages, so this evens out.

Doh!

Quote:

>Some MMUs store the ASID (logical address space identifier) in the TLB
>so that a flush is not required on every process switch.

>Only the most bare-bones RISC machines do TLB management (flushing and
>table-walking) in software instead of hardware.

>> I am in no position to denigrate wild speculation :o)

>OK, then let me make a few observations.

>The ability to spawn new processes and manage the memory for them is
>actually rather straightforward. The real key is figuring out exactly
>what sort of memory-sharing, interprocess communications and synchro-
>nization mechanisms are most appropriate for the types of applications
>a multiprocessing Forth would be used for.

>(What sort of IPC mechanisms, if any, do Forths for existing
> multiprocessing OSs support? All my Forth experience was on
> single-tasking systems like CP/M and on embedded systems.)

I have an OS design sketch I've posted here at
ftp://linux01.gwdg.de/pub/cLIeNUX/interim
a 40k text file. It posits "everything is a device". Processes can publish
driver-like services. That's a form of IPC. The memory-sharing issue that
raises is that processes providing virtual device services have to (well,
would run best if they could) read the address space of the caller, i.e.
the other process that is using thier service. I think it's soluble
though.

Quote:
>The basic "fork" style of spawning with copy-on-write could actually
>work rather well for the basic dictionary-and-two-stacks memory
>architecture of Forth, where much of the dictionary (except for embedded
>data structures) would remain shared throughout the life of the system.

Perhaps. My design doesn't have fork though, without a login. Long story
:o)

Quote:
>It might also be useful to have a thread-fork in which the dictionary
>is fully shared even for writes, and only the stacks are unique to each
>thread.

I think OS/2 maps the whole kernel into each process's space. Not real
appealing.

Quote:
>This is really starting to move into the area of OS design. Things to
>think about:
>* processes can be spawned; how do they die and/or get killed from
>  other processes?
>* how is CPU time allocated among processes and/or threads?
>  Cooperative? Preemptive? Priorities?
>* how much of this is handled by the "kernel" (whatever that is) and
>  how much by ordinary processes?

>It might be instructive to work this from the other end -- take a
>microkernel OS like Minix-VMD and see how much of it you'd want and
>how you might implement it in Forth.

Just at the design level I think. Something Jeff Fox said once that really
resonated with me was

        Design from the top, build from the bottom, consider everything.

Rick Hohensee

        www.clienux.com



Sat, 07 Feb 2004 10:55:17 GMT  
 Protected memory and Forth


Quote:
>Some MMUs store the ASID (logical address space identifier) in the TLB
>so that a flush is not required on every process switch.

But selectively eliminating entries with a to-be-reused ASID is
harder; flushing still works in that case, though.

Quote:
>Only the most bare-bones RISC machines do TLB management (flushing and
>table-walking) in software instead of hardware.

AFAIK TLB miss handling is in software on most RISCs.  The only ones I
know of that have at least partial hardware support for that are the
PPCs, and even there the software-only way can be faster, if you can
use it:

  author =       {Cort Dougan and Paul Mackeras and Victor Yodaiken},
  title =        {Optimizing the Idle Task and Other {MMU} Tricks},
  crossref =     {osdi99},
  pages =        {229--237},
  url =          {http://hq.fsmlabs.com/~cort/papers/linuxppc-mm/linuxppc-mm.ps},
  annote =       {Discusses various optimizations of memory management
                  stuff in Linux/PPC. The optimizations are: mapping
                  the kernel with BAT (block address translation)
                  registers instead of the TLB; better choice of
                  segment IDs (VSIDs) to get a higher hash table hit
                  ratio; hand optimizing the TLB miss code; on the
                  603, don't use the hash tables upon TLB miss, use
                  the page tables directly; instead of flushing stale
                  entries from the TLB and hash table, just change the
                  involved VSID; turn off the cache on TLB miss to
                  avoid polluting the cache with page table entries;
                  clear free pages in the idle task, with caches
                  turned off. Not all of these optimizations are
                  supported with convincing data in the paper, but the
                  effect of their combination is quite good. One
                  interesting result was that apparently the kernel
                  compile benchmark was originally suffering quite a
                  lot from TLB misses (just mapping the kernel with
                  BATs reduced wall-clock time by a factor 1.25).}

Quote:
}


  title =        {Operating Systems Design and Implementation (OSDI '99)},
  booktitle =    {Operating Systems Design and Implementation (OSDI '99)},
  year =         {1999},
  key =          {OSDI '99}

Quote:
}
>>(What sort of IPC mechanisms, if any, do Forths for existing
> multiprocessing OSs support?

Gforth supports files and pipes, and a C interface that can be used
for all mechanisms supported by C (but the C interface is not yet in
its final state).

There's also the in-Forth multitasker, which would probably be called
a thread library with cooperative thread switching in Unix circles;
communication between tasks can of course be done through shared
memory, syncronization is achieved by not putting task switching words
in critical sections.

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed

http://www.complang.tuwien.ac.at/anton/home.html



Sat, 07 Feb 2004 17:08:47 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. Shared Libs and protected memory

2. Share libs and protected memory (cont.)

3. Error - BASE/5300: Memory Low in Protected Mode App

4. HELP - CA Tools in protected memory mode

5. Question regarding Protected Mode Memory Mapping(Segmentation)

6. Protected Mode - DPMI & Memory Access

7. Protected Mode Video Memory

8. Protected mode memory

9. in protect mode, where is display memory area ?

10. Protected mode memory access in real mode problem?

11. Protected Mode memory addressing

12. Memory mapped I/O in protected mode

 

 
Powered by phpBB® Forum Software