Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


System call handler and Interrupt handler...MIPS...I'm confused...

This topic is 5354 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi!I''m new in assembly programming and i''d like your help. My problem is that i can''t underestand the true difference between the SYSTEM CALL HANDLER and the INTERRUPT HANDLER. Please let me give you a specific example...My example is based on the SPIM(mips simulator),but i guess everyone with some assebly background would be familiar with that. Well,SPIM uses a memory-mapped input/output...It has a special adress for receiving data from the keybord and a special adress for putting charachters that will be printed on the screen.So,i/o takes place by simply storing and loading words in those 2 adresses... Now...When someone uses SPIM,he/she can output,input characters using some systemcalls.This can be done putting the type of syscall into $vo register,specifying the arguments(eg. string to print) and then calling "syscall". Here''s the confusing part.(at least for me...) Let''s suppose that we want to output an integer which is placed in general purpose register $8... If i remember correctly,we would put 4(number of "print integer" syscall) in $v0,put the value of $8 in $a0(argument register) and call "syscall"... Now,what i know is that...Firstly the system-call handler will save the status of the inturrupted programm,examine the type of systemcall, and jump to the specific operating system routine...That routine will take the integer from $a0 and put in a buffer... What i underestand,is that in that point the job of the system-call handler finishes and the interrupt handler takes action... So now, the interrupt handler routine will take the character from the buffer and put it in the rght memory adress in order to be printed...Then,that handler will restore the status of the interrupted programm and finish its job... Now my questions.. 1)As far as i know the OS keeps an interrupt vector table...Does it also keep a SYSTEM CALL table?How is that different from The interrupt table? 2)Is the system call handler that calls the right interrupt handler routine? 3)Are interrupt handler and interrupt handler routine the same thing?Or the interrupt handler is a standalone programm,that its job is to jump to the right interrupt routine...? Anyway...Could PLEASE someone explain to me how the above example works?PLEASE...Enlighten me.. Thanks a lot...

Share this post

Link to post
Share on other sites
I am entirely unsure of specifics of MIPS, but it is generally the case in microprocessors that hardware and software interrupts are not treated vastly differently.

I have used 8-bit processors, where hardware and software interrupts are essentially the same.

When an interrupt happens (hardware or software), it saves some registers and jumps to the address at the vector. It typically does this in hardware.

In the case of a software interrupt, the OS handles it differently, in that it may return modified values of the registers. Doing so after a hardware interrupt would definitely crash.

On Intel 8080-like processors, software and hardware interrupts are basically the same too (At least until 686 when a new SYSCALL instruction was introduced or something)

On protected mode processors, an interrupt causes the CPU to go into supervisor mode, enabling it to execute privileged code. This means that when a user-level process asks the OS to open a file, it can write to the disc controller asking it to read the disc (something which the user-level process would not be able to do itself)


Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!