OSnews Asks: CPU IO Ports on Non-x86 Architectures
Linked by Hadrien Grasland on Fri 30th Dec 2011 08:24 UTC
Hardware, Embedded Systems In the world of alternative OS development, portability across multiple architectures is a challenging goal. Sometimes, it may be intrinsically hard to come up with hardware abstractions that work well everywhere, but many times the core problem is one of missing information. Here, I aim at learning more about the way non-x86 architectures deal with CPU IO ports, and in particular how they prevent user-mode software from accessing them.
E-mail Print r 5   · Read More · 75 Comment(s) http://osne.ws/jne
Permalink for comment 501991
To read all comments associated with this story, please click here.
Anachronda
Member since:
2007-04-18

Not quite. 00 is user space. But the stack started at 01 and worked down (so the first usable byte is in 00). DCL, RMS,and such lived in 01. 10 was where the kernel resided. 11 was reserved, but where all the physical devices lived.

Yeah, I knew I had botched 10 and 11 just after I posted it.

It mapped entire bus systems (UNIBUS,QBUS, BI...) The system was mapped this way because that was the only way system calls could be made. The CMx (change mode to Kernel/whatever) instructions would not work in P0 space, system calls were an entry into P1/P2 address pages, and the first instruction was required to be a CMx instruction (then followed by a jump), otherwise an illegal access fault occurred.

Hmm. I don't see those restrictions on the CHMx instructions in the VAX Architecture Reference Manual. The only restrictions I see are that CHMx cannot be executed while running on the interrupt stack and the new mode has to have enough privilege to access the old mode's stack.

It was interesting with the boot code - it always emulated a PDP-11 during initial boot, with the default peripherals always mapped to 017xxxx (octal) address range. Didn't matter which bus was mapped (QBus/UNIBUS or the BI), that was where the peripherals were mapped by default. Once SYSBOOT was loaded, it (meaning the loaded boot program) would switch to native mode and initialize all the hardware and load the kernel.

I'm curious about which machine you worked with. The big machines tended to have a captive PDP-11 (LSI-11 in the case of the /780, various Pro models in 8xxx machines). As I understand it, the PDP-11 was responsible for loading the microcode into the processor and the bootstrap into memory, then lighting off the VAX.

QBus machines tended to be built with processors that didn't support compatibility mode. At reset, they'd start running VAX code from ROM, which would go fetch the bootstrap.

I'm not sure how the /730 and /750 booted.

Reply Parent Score: 1