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.