[comp.arch] Is the Intel memory model safe from

aglew@urbsdc.Urbana.Gould.COM (05/16/88)

>In article <1988May12.162207.16764@utzoo.uucp> Henry Spencer writes:
>Probably because practically every machine in existence routes *all*
>traps and interrupts to the kernel, which can pass them on to the user
>if it pleases.  I know of no machine, offhand, whose hardware has any
>notion of a "user handler".

On Gould Powernodes (also, I believe, on Gould NP1's) traps and 
interrupts are controlled by {trap,interrupt} control blocks
(TCBs/ICBs) that contain a slot for the old PSD and a bit of 
status to be stored in, and a slot for the new PSD.
   The PSD controls which memory map is active during the interrupt
routine, whether mapping is active or not, and whether the interrupt
routine can execute priviliged instructions or not.
   The TCBs are under kernel control (they are addressed physically)
but can be used to dispatch into user context. We currently do this
for "Directly Connected Interrupts"(tm), where the (priviliged) user
gets to write the actual interrupt code, which executes in his map.
I have also used it for statistics gathering programs, eg. an 
attachable profiler.
    In both of these applications the user interrupt handler runs
priviliged (they are oriented towards the type of application that
wants 100% control of the machine), but it would be easy enough to
let them run unpriviliged, with arrangement via a system call or
trap to perform the priviliged return from interrupt.



Andy "Krazy" Glew. Gould CSD-Urbana.    1101 E. University, Urbana, IL 61801   
    aglew@gould.com     	- preferred, if you have MX records
    aglew@xenurus.gould.com     - if you don't
    ...!ihnp4!uiucuxc!ccvaxa!aglew  - paths may still be the only way
   
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.

aglew@urbsdc.UUCP (05/18/88)

>Hang on a sec--doesn't the fact that the VAX uses the first two address
>bits to determine which page table to use mean that it has Intel-ish
>segmentation?  Seems to me that 30 bits has been big enough so far.
>Has anyone out there ever written a program that used up a VAX's
>virtual memory?
>
>       Duke Robillard
>       AT&T Bell Labs           m10ux!rgr@att.UUCP                 
>       Murray Hill, NJ          {backbone!}att!m10ux!rgr

(1) Use of address bits to divide memory into sections is not the same
    as segmentation. In a segmented architecture, the segment address
    and the offset are logically separate. In machines that divide
    the addresses into fields, the implementation distinguishes between
    the fields, but the instruction set itself does not - using the 
    normal instructions that do arithmetic on addresses, one can 
    increment an address pointer and change the high order bit fields.

    eg. char *p; for(p=(char*)1;p;p++);
       will eventually step over all memory addresses, as long as it 
       doesn't fault. This is not true on a segmented machine, and is
       both the weak and strong point of segmentation.

(2) Yes, there are programs that can use more than 4GB of virtual 
    memory. 


Andy "Krazy" Glew. Gould CSD-Urbana.    1101 E. University, Urbana, IL 61801   
    aglew@gould.com     	- preferred, if you have MX records
    aglew@xenurus.gould.com     - if you don't
    ...!ihnp4!uiucuxc!ccvaxa!aglew  - paths may still be the only way
   
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.