Live data from Hacker News

80386 Early Start Memory Access

nand2mario.github.io

1–10 of 10 posts

Re: 80386 Early Start Memory Access

#5
I wonder how the logic worked in the previous version without early start. Was it relying upon the address calculation speed to settle the outputs really quickly? Was it inserting or stretching cycles?

Re: 80386 Early Start Memory Access

#6
post #5

I wonder how the logic worked in the previous version without early start. Was it relying upon the address calculation speed to settle the outputs really quickly? Was it inserting or stretching cycles?

The memory pipeline just starts one cycle later than now. Effective address is calculated during the first cycle of the instruction. The microcode then waits for it to finish with the DLY (delay) micro-op, which releases one cycle later.

Re: 80386 Early Start Memory Access

#9
post #5

I wonder how the logic worked in the previous version without early start. Was it relying upon the address calculation speed to settle the outputs really quickly? Was it inserting or stretching cycles?

The memory pipeline just starts one cycle later than now. Effective address is calculated during the first cycle of the instruction. The microcode then waits for it to finish with the DLY (delay) micro-op, which releases one cycle later.

So cycle insertion. I presume that the DLY was synthetic, and was not explicitly added to the microcode ROM.

Re: 80386 Early Start Memory Access

#10

I wonder what exactly stops windows from booting

Probably some protected mode logic bugs. Just need more time to debug through the boot process.

I wouldn't be surprised if it is lurking in some part of (say) the TSS that you thought that you'd never have to implement.