Linked by Hadrien Grasland on Sun 27th Feb 2011 12:06 UTC
Permalink for comment 464258
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 06/19/13 23:02 UTC, submitted by M.Onty
Linked by Thom Holwerda on 06/19/13 22:28 UTC
Linked by Thom Holwerda on 06/18/13 22:33 UTC
Linked by Anonymous on 06/18/13 22:26 UTC
Linked by Thom Holwerda on 06/18/13 22:25 UTC
Linked by Thom Holwerda on 06/18/13 17:45 UTC
Linked by Thom Holwerda on 06/18/13 17:32 UTC, submitted by poundsmack
Linked by Thom Holwerda on 06/17/13 17:58 UTC
Linked by Thom Holwerda on 06/17/13 17:52 UTC
Linked by Thom Holwerda on 06/14/13 21:03 UTC
More News »
Sponsored Links



Member since:
2007-04-06
In my somewhat limited experience, the basic idea of interrupt handling is pretty universal across platforms. An interrupt comes in, consults the vector table and jumps to appropriate address/service routine. Variation comes into play wrt how the table is accessed, how and what sort of masking can take place, etc. I don't anticipate it would be too difficult to abstract that away.
You'd basically hook a couple of function call like:
void program_isv(int interrupt_number, &service_routine() );
int mask_interrupts(int interrupt_mask);
etc, making them implementation specific. But while I've worked on embedded systems, I've never written my own kernel (from scratch), so take that with a significant grain of salt.
I think some of our earlier commenters are too kind on the 68k line. It was a good architecture, make no mistake, but among other things, the instruction set was too bloated. It was partly because of CISC processors like the 68k that we saw such a movement toward much more RISC processors like ARM, culminating in excessively small ISs like the ridiculous PIC. But anyway. Such are my opinions.