Interrupts, bus request operations

[PainterGuy]

TL;DR Summary

Some questions about the text on interrupts and bus request operations.

Hi,

Could you please help me with the queries below?

Please have a look on this attachment.

Question 1:
It says, "Because the processor cannot know when an interrupt will occur, it automatically saves on the register stack status information about the program that is executing at the time the interrupt or exception occurs."

In my opinion, the text suggests that the processor always keeps itself ready to serve an interrupt, in other words it's always expecting an interrupt, but then it suggests something somewhat contradictory that the processor saves information at the time the interrupt occurs.

Question 2:
The text also says, "Software reset This is a software exception and is sometimes called a warm boot. This also restarts the system but bypasses many of the hardware initialization tasks performed by a cold boot."

I also checked online and found the following definition. I believe that software reset or warm boot refers to the RESTART from START MENU on Windows computer. I had always thought that the software reset clear all the contents of memory because your computer does start afresh and you can't find any trace of previously running program(s).

warm boot
Reloading the operating system by performing a Restart operation from the computer's main menu while it is still turned on. The warm boot does not turn the power off and back on, and it does not clear memory. Contrast with cold boot.
Source: https://www.pcmag.com/encyclopedia/term/54212/warm-boot

Question 3:
Now please have a look on this attachment.

It says, "Secondly, in a bus request operation, the processor passes control of the system buses to the requesting device, which then handles all bus operations. The processor continues to execute instructions in the ISR or exception handler during interrupts."

If the processor passes control of all the buses to the requesting device then how could it keep on executing instructions in the ISR or exception handler during interrupts? Doesn't it need to regain the control of buses back to serve the interrupts?

Thank you for your help!

 

[phinds]

Question 1:
It says, "Because the processor cannot know when an interrupt will occur, it automatically saves on the register stack status information about the program that is executing at the time the interrupt or exception occurs."

In my opinion, the text suggests that the processor always keeps itself ready to serve an interrupt, in other words it's always expecting an interrupt, but then it suggests something somewhat contradictory that the processor saves information at the time the interrupt occurs.

I think you are simply confused by the wording. In a sense, the computer IS always "expecting" an interrupt because it is always able to handle an interrupt, but it isn't DOING anything about that "expectation" until an interrupt actually occurs, at which time it saves information and jumps to the interrupt location. Put another way, the CPU is indifferent to the possibility of an interrupt because whenever an interrupt occurs, it will be properly handled.

 

[rcgldr]

Somewhat similar, the loop instruction on X86 on 386 or later processors is slow because the branch may cause a page fault, and the loop instruction will have to be repeated. This means that cx/ecx/rcx has to be backed up before performing the loop instruction, so that cx/ecx/rcx can be restored after handling a page fault. This means that dec cx/ecx/rcx followed by jnz is faster.

 

[PainterGuy]

Thank you for your help!

Yes, I was more confused by the wording.

Could someone please comment on Question 2 and Question 3? Thanks a lot.

 

[Rive]

I had always thought that the software reset clear all the contents of memory because your computer does start afresh and you can't find any trace of previously running program(s).

The OS by default does not expect anything about the unused memory: it is not that it can't find any traces, but it won't look for. Due safety issues it is possible that before assignment of memory areas it clears them, but it is not an actual requirement.
So in case of 'soft reset' there might be data left in the memory somewhere.

Summary: Some questions about the text on interrupts and bus request operations.

If the processor passes control of all the buses to the requesting device then how could it keep on executing instructions in the ISR or exception handler during interrupts? Doesn't it need to regain the control of buses back to serve the interrupts?

- you remember 'cache'? The CPU has a slice of the memory available 'off-bus'. (In case the 'requesting device' has some business with a cached memory area... well, that's trouble and requires many further logic to resolve 'coherence'.
- usually the bus is requested only for a few bus cycles and then it is released for CPU usage. But 'bus mastering' is also a very big topic in itself.

 

[anorlunda]

Summary: Some questions about the text on interrupts and bus request operations.

I had always thought that the software reset clear all the contents of memory because your computer does start afresh and you can't find any trace of previously running program(s).

I expect each OS to make its own policy about clearing memory.

In a low security environment, forgetting which memory was used for what purpose, is a pretty good scrambling. But for more security an actual memory clear might be necessary. And for some types of physical storage, multiple passes of data scrubbing may be necessary.

It sounds like you are reading your textbook too literally. The real world and natural language allow for wide ranges of behavior and meanings for the same words.

 

[PainterGuy]

Thanks a lot for your help!

- you remember 'cache'? The CPU has a slice of the memory available 'off-bus'.

I did have cache memory and CPU registers in mind but didn't take them into consideration because they allow for extremely limited storage.

It sounds like you are reading your textbook too literally. The real world and natural language allow for wide ranges of behavior and meanings for the same words.

Agreed. But it has been my experience that many a time asking a senior helps you and one could learn better. To be honest, in real world, like for exam studies, one should never ask or bother oneself with these questions. Just cram it up and get decent grades.

 

[Tom.G]

To be honest, in real world, like for exam studies, one should never ask or bother oneself with these questions. Just cram it up and get decent grades.

That sort of depends on your ultimate goal.

If "Getting a high grade" and "Getting a piece of paper to hang on the wall" are your goals, then yes, that approach could work.

Conversely, if you want to understand things as a basis for further understanding, and to be competent, innovative, and sought-after in your chosen field, then digging in for a deep understanding is the preferred route. For many people it is also the more enjoyable route!

Anyhow, that is my opinion. Many people considered "successful" have started out following the first route.

Cheers,
Tom

 

[Rive]

they allow for extremely limited storage.

Bus requests are usually just a few (bus)cycle anyway, and usually this kind of memory access from some IO controller is still faster than asking the CPU (by an interrupt, for example) to do the same transfer (CPU would need to move the code too, apart from the data movement).
There are cases when stopping the CPU is not tolerable (either interrupts or bus requests), but that's a different art.

 

[PainterGuy]

Thank you!

Many people considered "successful" have started out following the first route.

You nailed it! First route is more secure and your success is guaranteed to a larger extent. One could get good grades and at the same time strive to understand the material but the understanding involves layer after layer, and many a time people get lost in those layers of understanding and end up without excellent grades. If one is primarily focused on getting grades, it makes the journey focused and comparatively easier. By the way, I have good grades and still a student but I still tend to advise people to take the first route.

There are cases when stopping the CPU is not tolerable (either interrupts or bus requests), but that's a different art.

In this attached text from Question 3, right under the highlighted part, the following is said, "A third difference is that once the processor grants the bus request and relinquishes the system buses, the processor cannot regain control of the system until the requesting device relinquishes control or the processor is reset."

It means that if the requesting device takes more than few bus cycles then the processor would need to halt itself until it regains the control. I'm sure that my interpretation is limited and narrow because the text is only trying to convey the basic idea of things.

Thanks a lot for the help and your time!

 

[Rive]

It means that if the requesting device takes more than few bus cycles then the processor would need to halt itself until it regains the control.

Yes, but the premise is, that doing the task of the other device through this direct way takes less resources than through software running on the CPU. So unless the system is deadlocked due a dysfunctional device it is still expected to be a win.