search

trillek / entropy

Entropy kernel for DCPU-16
8 stars 6 forks source link

Handling interrupts, work-around now, but where to go? #14

Open thePalindrome opened 12 years ago

thePalindrome commented 12 years ago

There's nothing in the code that handles interrupts, but locally I've got some multitasking code that takes in all the interrupts...

So here's what the interrupt handler needs to do...

  1. It needs to be set as the handler using IAS
  2. it needs to know where each interrupt message goes
  3. it needs to allow removing interrupts
  4. it needs to prevent duplicate messages

So, when we do have the handler pushed, two things to keep in mind:

Message A=1 is MINE, for the multitasker in multitasker.dasm, the init function has the IAS line, make sure to remove it!

Liraal commented 12 years ago

Lucus is writing a dynamical interrupt handler, you should probably contact them.

thePalindrome commented 12 years ago

Well, that's kind of what this issue was made for, because Lucus isn't on right now!

dilbertfan commented 12 years ago

Lets interrupt his life and get him online

shittypun

ColErr commented 12 years ago

For hardware, I think the best thing to do is make the interrupt message the location of the handler. This would save loads of time on checking messages to see who is handling them, you just need to have it jump to A and be done with it.

Lucus16 commented 12 years ago

Hey guys, I'm back, will resume making interrupt handler now, last I remember there were some issues which I had to decide about, as soon as I remember what they were, I'll post here.

EDIT: See Issue 16: Communication

M52 commented 12 years ago

@ColErr I agree. That would be best. Even more so because this way people could, if they want to, override our hardware handlers (keyboard, lem) and replace it with their own. Though I do not suspect anybody would want to seeing as we spend alot of time discussing our implementations, hence our implementations will probably be the "best" (fastest, smallest) anyway...

Lucus16 commented 12 years ago

That is actually a pretty neat idea, the problem is this would mean the process would get to run immediately. The interrupt needs to wait with being raised until it's target process gets running time again. And if, during this wait, another interrupt comes in, it needs to be queued.

We could of course also decide to let processes handle interrupts immediately, but they'd be stealing time from other processes.

Liraal commented 12 years ago

Add a little stack (no more than 0x10 words) for each process to store their interrupts there. When the process gets running time, you'll just pop an interrupt from the respective stack.