Re: Universal grammar

"Paul" == Paul J Kriha <paul.nospam.kriha@xxxxxxxxxxxxxxx> writes:

Paul> Oh, fluf. Of course the address of the actual interrupt
Paul> vector MUST BE HARDWIRED in the CPU. When an interrupt
Paul> signal reaches it, th CPU finishes the current instruction
Paul> and if not prevented by interrupt masking it slavishly jumps
Paul> at a hardwired address in the interrupt vector table. The
Paul> contents of the interrupt vector table are in turn
Paul> programmable which means we can define where the actual
Paul> interrupt server support code resides.

To me, "hardwired" and "programmable" are opposite.


Paul> If you are using IBM compatible PC,

Yes, but you've assumed something wrong...


Paul> go to Accessories, System Tools, and start System
Paul> Information. Expand "Components", click on "Ports".

Um... where is "Accessories"? I'm using Linux + FVWM.


Paul> Look at, for example, IRQ4 (interrupt pin number 4). IRQ4
Paul> is dedicated to the serial interface COM1:. Since the
Paul> beginning of time (early eighties) its _hardwired_ eight
Paul> byte interrupt vector is sitting at addresses x03F8 to
Paul> x03FF. Remember, x03F8 is _hardwired_ in the CPU!!!

That's not hardwired in the _CPU_. It's hardwired in the
_south-bridge chipset_. In earlier implementations, it's hardwired
into the Multi-I/O adaptor which provided the RS232 port.

Further, I/O address 0x03F8 isn't related to interrupts at all. It's
an I/O address. The RS232 port uses IRQ (== interrupt request) #4 on
my system. This IS the interrupt id.

$ cat /proc/interrupts
CPU0 CPU1
....
4: 10 0 IO-APIC-edge serial
....


$ cat /proc/ioports
....
03f8-03ff : serial
....



Paul> When COM2 serial communications device drops the voltage on
Paul> the interrupt pin IRQ3, the CPU will use hardwired addresses
Paul> x02F8-x02FF to tell it where the actual code to serve this
Paul> interrupt is. Remember, x02F8 is _hardwired_ in the CPU!!!

You're still confusing:

a) interrupt signal with reset signal
b) I/O port address with IRQ number
c) which part of the computer determines that I/O port 0x3F8 is mapped
to the first RS232 port



Paul> At that level the main (and often the only) difference
Paul> between various interrupts is the actual code stored at
Paul> those addresses (they usually happen to be further jump
Paul> instructions to various blocks of codes implementing the
Paul> various h/w servers).

You still haven't noticed that interrupts are meant for:
a) peripherals to get attention from the CPU;
b) resumable operation (i.e. after the interrupt handler completes, control
is transferred back to the original instruction that was interrupted.)

While the reset signal is meant for:
a) bringing the whole system, CPU included, to an initial state;
b) a one-way street. There is no return.



Paul> It depends on which CPU we talking about

I'm familiar with 2 CPU families: 6502 and ix86. Both handle reset
and interrupts differently, as I described.


Paul> but these days the actual functionality is almost exactly
Paul> the same as executing a common subroutine jump.

You mean a RESET is returnable?


Paul> Usually the CPU invokes the same internal microcode to store
Paul> current context on the stack and so on.

Why store the current context upon a RESET?


Paul> Some architectures have a separate interrupt stack to make
Paul> sure that the CPU doesn't run out of stack memory while
Paul> attempting to service a critical interrupt.

Yeah. Is that stack ever used in case of RESET? How? For what?


Paul> If you manage to change these arrays of jump instruction,
Paul> aka interrupt vectors, you modify the function of the
Paul> interrupts lines. So on many old as well as new CPUs you
Paul> could swap functionality of reset line and say disk channel
Paul> interrupt. (Not that one would normally want to do that).

Have you tried that?


>> No. A RESET signal is different. A RESET causes the CPU to
>> clear its register contents, reset the "address for next
>> instruction" to some *hardwired* value, and execute instruction
>> from that address onward. No return address is saved onto the
>> stack, because the CPU is *not* expected to *resume* from a
>> RESET signal. (Actually, the stack is also reset by clearing
>> the stack-pointer register. So, it's meaningless to store a
>> return address.)

Paul> Some of what you say here is done by the init code in the
Paul> PROM not by CPU internal microcode as you imply.

I see. But at least, the 2 families of CPU's I'm familiar with do not
do so. They both have separate reset signals which causes the CPU to
do very different things.


Paul> It's totally unnecessary to waste expensive microcode memory
Paul> to perform tasks unique to RESET interrupt which get
Paul> performed only once in a blue moon.

Well... many people have to RESET their computers once in a blue
screen! ;)



>> Purpose: RESET: It is usually a system-wide signal. Not only
>> the CPU but also peripherals react to this signal and go to an
>> "initial" state.

Paul> This is all pure fantasy. There is no system-wide RESET
Paul> wire going to all peripherals.

Are you 100% sure?



--
Lee Sau Dan 李守敦 ~{@nJX6X~}

E-mail: danlee@xxxxxxxxxxxxxxxxxxxxxxxxxx
Home page: http://www.informatik.uni-freiburg.de/~danlee
.

Relevant Pages

  • Re: Universal grammar
    ... Paul> This is a software engineers vocabulary. ... Paul> reset and other h/w interrupts. ... Paul> between how a CPU reacts to signals on various interrupt ... Paul> hardware device interrupts cause the CPU interrupt whatever ...
    (sci.lang)
  • Re: Universal grammar
    ... RESET cannot be caught or masked. ... INTERRUPT is caught, handled and then the system resumes from it. ... INTERRUPT is used by peripherals to catch the attention of the CPU, ... Paul> Hans is absolutely correct. ...
    (sci.lang)
  • Re: Universal grammar
    ... Paul> This is a software engineers vocabulary. ... Paul> reset and other h/w interrupts. ... Paul> between how a CPU reacts to signals on various interrupt ... Paul> hardware device interrupts cause the CPU interrupt whatever ...
    (sci.lang)
  • Re: Is it possible to have a 4KHz hard real time interrupt?
    ... Thanks Paul and Chris, that article and feedback is great, exactly what I needed ... It is something 'spinning', and requires very consistent and time ... and direct to the interrupt service routine without RTOS intervention. ... > sub-us latency, I think that you're looking at a special-purpose processor, ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Universal grammar
    ... Hans> Only you can improve your computer skills. ... Paul> Which is just one of the hardware interrupts that can be ... RESET cannot be caught or masked. ... INTERRUPT is caught, handled and then the system resumes from it. ...
    (sci.lang)
Loading