OSDev.org https://forum.osdev.org/ |
|
iret and ret ? https://forum.osdev.org/viewtopic.php?f=13&t=21803 |
Page 1 of 1 |
Author: | Sam111 [ Mon Apr 05, 2010 6:47 pm ] |
Post subject: | iret and ret ? |
I have read this Quote: The difference between IRET and RET is that IRET pops an extra 2 bytes off the stack (the flags register is popped). An interrupt call always pushes the flags onto the stack before pushing on the far return address. In general, hardware interrupt handlers use an IRET statement while software interrupt handlers use a RETF 2 (far return) statement I have made a utility.asm file which looks like this Code: set_graphics_mode: mov ah , 00h int 10h pop ax ret ....etc And I am calling it in my other asm files by Code: mov ax , 00h push ax call set_graphics_mode but I my questioning should I use iret in the utility.asm functions if I am using an interrupt or just the regular ret. Basically is the iret only used at the end of your homemade interrupt or irq function or when a function is calling an interrupt and returning to the callee. I know from the above quote iret pops the extra flags register on the stack. But apart from that I don't see if their is any other difference between iret and ret...? As well when you call int 10h or something what gets pushed on the stack just the flags register? Or could you do the equivalent of an int 10h call by pushing the flags register eflags onto the stack and doing a jump to the int 10 interrupt address in the IVT. Curious? Thanks for any help |
Author: | Gigasoft [ Mon Apr 05, 2010 7:59 pm ] |
Post subject: | Re: iret and ret ? |
When you cause a software interrupt, the flags register is pushed followed by CS and IP. The iret instruction does the reverse, it pops IP, CS and then the flags register. Yes, you can invoke an interrupt by doing a pushf and then (assuming that DS is set to 0 and you want to invoke int 10h) call far word ptr ds:[40h]. Only the lower 16 bits of the flags are pushed when in real mode. Only interrupt handlers should return using iret. Normal procedures such as set_graphics_mode should use ret if they are called with a regular call, and retf if they are called using a call far instruction. I don't know what you're trying to accomplish with the push ax and pop ax, but it definitely won't work. If you want to use a parameter that was passed on the stack as the graphics mode, the function should be written in one of the following ways: Code: set_graphics_mode: push bp mov bp,sp movzx ax,byte ptr [bp+4] int 10h pop bp ret 2 Or: Code: set_graphics_mode: pop cx pop ax push cx mov ah,0 int 10h ret If you just want to pass the parameter in AL and not on the stack, the code would be: Code: set_graphics_mode: mov ah,0 int 10h ret There is one additional difference between retf and iret. If NMIs are masked, iret unmasks them. In protected mode however, interrupts and iret work in a completely different way. |
Author: | Love4Boobies [ Tue Apr 06, 2010 5:57 am ] |
Post subject: | Re: iret and ret ? |
Sam111 wrote: I have made a utility.asm file which looks like this Code: set_graphics_mode: mov ah , 00h int 10h pop ax ret ....etc And I am calling it in my other asm files by Code: mov ax , 00h push ax call set_graphics_mode There are only disadvantages to what you're doing:
|
Author: | Sam111 [ Tue Apr 06, 2010 8:30 am ] |
Post subject: | Re: iret and ret ? |
OK , I am just curious on why this won't work? Code: read_character_and_attribute: push bx push cx push dx mov ah , 08h int 10h pop dx pop cx pop bx ret basically I pushed the variables bx , cx , and dx onto the stack to safe their values call the int 10h then pop all the dx , cx , and bx values back into the dx , cx ,and bx registers and return to the callee. What is wrong about that? When you use the call instruction does it push anything on the stack before it goes to the function. If so can a call instruction be translated into an equivalant jmp instruction with a few push instruction or something? (I would think the call instruction only pushes the return address on the stack but I could be forgetting something.) And ret just jumps back to the return address and pops it off the stack though I don't know in what order...? So I would think ret could be translated into an equivalant jmp to return address and pop return address of the stack (i.e a jmp command and a pop command) ??? Curious if this is the same as ret Code: jmp sp <--return_address pop sp or for 32bits jmp esp <---return_address pop esp Thanks |
Author: | bewing [ Tue Apr 06, 2010 9:13 am ] |
Post subject: | Re: iret and ret ? |
Call = Code: PUSH EIP JMP $FUNCTION Ret effectively pops the old EIP off the stack into a hidden register, then does a JMP to the value in that hidden register (so you have the order backwards above). And to answer your original question: using interrupts is very very slow. In Pmode, it is one of only 3 ways to handle "privilege level switching" -- from usermode to kernelmode, so you may be FORCED to use it because you have no other real choice. If you are not in Pmode, then it is always better to use CALL/RET rather than INT/IRET for writing functions. And your code example above should work fine. It does just what you say. That INT 10h function may also trash the value in AX -- if you care about any other registers than BX, CX, DX, then you need to look at RBIL and see which registers get overwritten with new values. |
Author: | Gigasoft [ Tue Apr 06, 2010 9:22 am ] |
Post subject: | Re: iret and ret ? |
Quote: OK , I am just curious on why this won't work? It should work, assuming that the registers were set correctly. Quote: Curious if this is the same as ret No. That would jump to the current value of ESP, and interpret the contents of the stack as instructions. And instructions that are placed after a jump instruction aren't executed. The following performs the same function as ret, but overwrites cx: Code: pop cx
jmp cx |
Author: | Sam111 [ Tue Apr 06, 2010 10:36 am ] |
Post subject: | Re: iret and ret ? |
Ok , I see But the first person that posted gave this Code: If you want to use a parameter that was passed on the stack as the graphics mode, the function should be written in one of the following ways: Code: set_graphics_mode: push bp mov bp,sp movzx ax,byte ptr [bp+4] int 10h pop bp ret 2 Or: Code: set_graphics_mode: pop cx pop ax push cx mov ah,0 int 10h ret If you just want to pass the parameter in AL and not on the stack, the code would be: I am wondering about the first set_graphics_mode as well as the second one. In the second one why does he do 2 pops and a push instruction ? Also this statement Quote: And to answer your original question: using interrupts is very very slow. In Pmode, it is one of only 3 ways to handle "privilege level switching" -- from usermode to kernelmode, so you may be FORCED to use it because you have no other real choice. If you are not in Pmode, then it is always better to use CALL/RET rather than INT/IRET for writing functions. well I am in 16bit mode and if I want to set a graphics screen resolution I would need to use an int command. I am curious though why int /IRETcommands is much slower then the call/ret commands. I thought the int command just pushed an addition flags registar on the stack as opposed to just pushing the cs ip registers on the stack....etc So it would only be one more thing it does more then the call command . Correct me if I am wrong. Also correct me if I am wrong when the computer first starts up the only thing we have availible function wise is the bios interrupts and the VGA/VESA graphics interrupts (i.e int 13h , int 10h ) Is their any other interrupts that are universial (i.e you can pretty much count on them to be availble at bootup) I know their is a list of interrupts ,...etc here http://www.ctyme.com/intr/int.htm and many other places but I am not sure how univerial they are for a particular computer . can you count on keyboard interrupts int 16h , mouse , sound ,...etc as well. |
Author: | Gigasoft [ Tue Apr 06, 2010 11:22 am ] |
Post subject: | Re: iret and ret ? |
Code: set_graphics_mode: pop cx pop ax push cx mov ah,0 int 10h ret First, the return address is popped. Then the parameter is popped into ax to be used with the int 10h. Then the return address is pushed again, so that the ret will use it. At startup, you can only count on standard BIOS interrupts (10h through 1ah). The discussion about speed is only relevant for code that executes many times repeatedly (for example, it would be a bad idea speedwise to use the BIOS set pixel service in a loop to fill a rectangle). |
Author: | Sam111 [ Tue Apr 06, 2010 12:06 pm ] |
Post subject: | Re: iret and ret ? |
Quote: The discussion about speed is only relevant for code that executes many times repeatedly (for example, it would be a bad idea speedwise to use the BIOS set pixel service in a loop to fill a rectangle). gotcha on all that. When I was in text mode I used the MMIO at 0xB8000 and every even array element /memory address corrosponded to the value and the odd address corosponded to the attribute (background color etc..) But now I put my monitor in graphics mode Code: 06 Graphics 2 80x25 640x200 1 B8000h I am wondering how to set a given pixel in protected mode since I have switch from real to protected 32bit mode. I am wondering if their is an equivalent MMIO for graphics mode??? Also is their any high resolution for text mode or is it just 80 by 25 or 40 by 25 because it would be nice to have really small texted maybe the only way is to do it in graphics mode.... Also when would you use MMIO at A0000h instead of B8000h ? Thanks for your help gotcha on the pop stuff as well . |
Author: | Gigasoft [ Tue Apr 06, 2010 1:02 pm ] |
Post subject: | Re: iret and ret ? |
All BIOS non-CGA graphics modes use addresses 0xA0000 through 0xAFFFF to access the screen. The screen in mode 6 is accessed at 0xB8000. Each line is 80 bytes long, and each byte represents 8 pixels where the MSB is the leftmost pixel. Even numbered lines are accessed at 0xB8000 and odd numbered lines at 0xBA000. Mode 6 is obsolete, and I recommend mode 12h instead. In mode 12h, every line occupies 80 consecutive addresses and the lines are stored sequentially. The screen is accessed at 0xA0000. Each of the 4 bits of the color index is stored in its own plane. Graphics register 8 selects the color planes to write to. For example, if the color plane number is stored in CL, this code will select it for writing: Code: mov ah,1 shl ah,cl mov al,8 mov dx,3ceh out dx,ax Mode 13h is easier to use. Here, the screen is accessed at 0xA0000 and the lines are stored sequentially. Each byte contains two nibbles which are translated according to the attribute palette registers and concatenated to form an 8-bit palette index. The following will change the number of rows in text mode to 50: Code: mov bl,0 mov ax,1112h int 10h To have 44 rows, you would use the code above followed by: Code: mov dx,3d4h mov ax,4809h out dx,ax mov ax,8b12h out dx,ax High resolution text modes can be programmed, but aren't part of the standard BIOS mode set. Some BIOSes offer them as VESA modes. |
Author: | johng [ Sat Dec 15, 2012 7:22 am ] |
Post subject: | Re: iret and ret ? |
please people, the only reason you use a 'ret' (00CBh) is to return to a caller sub-routine. if your subroutine uses an interrupt 'INT XX' then the next command on return from the interrupt is the next command only, as i say 'unless you 'accessed' the sub-routine containing the interrupt from another sub-routine containing the 'call' (00E8h) command. the 'call' and 'ret' command go hand-in-hand. now, unless you are going to be writing your own "interrupt" routines a task i don't suggest anyone try without at least five years professional experience and a command by command knowlege of the entire bios of the computer that you are using, you have NO need of understanding of the workings of the 'IRET' command as this command is used most commonly by the bios to return control, by and from, the internal system, from the internal workings of a bios only routine to the subroutine that you have written. look, for those of you who ARE more than a little curious about how GRANPA IBM does things, there are, or were, a couple of really engrossing publications available on specifically this subject,... they are The DOS 5 Bible by Steven Simrin, and, Assembly Language TUTOR by Richard E. Haskell, upon acquiring a copy of both these thomes you may consider yourself in a 'real' position if you are on Windows to navigate to C:\Windows\system32\cmd.exe, put a shortcut for cmd.exe to the desktop, double-click on it, the whilst DOS is coming up, turn to the section on 'DEBUG' in the DOS 5 Bible, then once DOS is on screen type 'debug' then start straining that grey-matter until it creaks.... all the best, johng |
Author: | bluemoon [ Sat Dec 15, 2012 7:34 am ] |
Post subject: | Re: iret and ret ? |
Please check the date before putting a reply This thread dead 2 years ago. johng wrote: i don't suggest anyone try without at least five years professional experience and a command by command knowlege of the entire bios of the computer that you are using, you have NO need of understanding of the workings of the 'IRET' command as this command is used most commonly by the bios to return control, by and from, the internal system, from the internal workings of a bios only routine to the subroutine that you have written. IRET is pretty much essential for OS development (look at the domain name of this forum), and it's not exclusive for BIOS. |
Page 1 of 1 | All times are UTC - 6 hours |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |