flat assembler
Message board for the users of flat assembler.

Index > OS Construction > delay after write to/read from port. when needed?

Thread Post new topic Reply to topic

Joined: 12 Apr 2005
Posts: 501
Location: Belarus
zhak 10 Apr 2015, 17:09
Old sources for various ports IO stuff (like reading from/writing to kbd ports) include delays in a form of JMP $+2 after IN/OUT operations. Well, if I recall correctly, this delay is not necessary on modern systems. Cannot find detailed info on the subject on the Internet. So, my questions are:
- on what processors this delay was necessary and why?
- since what processors the delay could be omitted?
- is it related to all peripheral devices or only very slow ones?
Any information and/or links are appreciated! Thanks in advance
Post 10 Apr 2015, 17:09
View user's profile Send private message Reply with quote

Joined: 31 Oct 2004
Posts: 557
smiddy 10 Apr 2015, 19:46
Your question is fairly general. I would say that there are a lot of different places where delays are need in order to allow peripherals a chance to do what is being requested. This is very specific to each peripheral though. As keyboards go, there are so many different types and so many different interfaces, to be general, it is worth studying each and understanding where they are needed for your particular application.
Post 10 Apr 2015, 19:46
View user's profile Send private message Reply with quote

Joined: 25 Aug 2004
Posts: 618
cod3b453 10 Apr 2015, 19:52
Speaking generally, this still is a problem for hardware today because the CPU operates much faster than the peripherals it is talking to. Most of the time this is the classic race condition of write a command and poll a status but it immediately returns "done" because the device hasn't even had time to process the request and switch to "busy" so it's still "idle". Introducing a sufficient delay was the only way to get around this problem.

Nowadays, this problem has been avoided by moving from PIO to interrupt-driven synchronisation except where real time is still important and the delay in handling an interrupt is too long.
Post 10 Apr 2015, 19:52
View user's profile Send private message Reply with quote

Joined: 22 Mar 2011
Posts: 272
Location: California
BAiC 11 Apr 2015, 06:04
on one very specific note: "jmp $+2" is never a valid method to delay the processor as it's not defined to produce a temporal delay.

in general a delay is needed in device/usage specific cases.

if you read from the SAME register as you wrote to then you don't need a delay as the processor doesn't re-order IO instructions. nor does the processor cache the earlier write (no write forwarding). only the IN and OUT instructions count as IO instructions. if you want MOV to behave like IN/OUT then you need complex MMU handling (Read up on MTRR, Memory Type Range Registers).

if you issue two writes to different registers then you don't typically need stalling between the two writes.

if you issue a write to the same register as an earlier write then you'll usually need a wait loop especially with older hardware.

all of that said; the majority of delays you'll encounter will be waiting for responses from hardware after issuing a command (a write) such as the standard ATA command if you use PIO.

some of the wait loops I can recall are:
ATAPI Packet Command (the ATA HDD using DMA and interrupts doesn't require a wait loop).
Floppy "Send Byte" command requires waiting for the device before sending each byte.
I think the Serial Port has the same type of delay as the floppy send byte.

there is also one other case you should be aware of but I've only seen it once in the Real Time Clock. for a small period of time (each second) the RTC goes offline preventing updates but not reads. to ensure correct usage you need a wait loop that ensures the current moment in time isn't an update cycle. if it's not an update cycle then you're free to write the registers. it's a strange case that can lead to deficient solutions (waiting for the update cycle to happen, then waiting for the update cycle to end) but it's one case that you should atleast be aware of.

- Stefan
Post 11 Apr 2015, 06:04
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum

Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.