Displaying 6 results from an estimated 6 matches for "retf".
Did you mean:
ret
2014 Oct 10
3
[LLVMdev] Stange behavior in fp arithmetics on x86 (bug possibly)
...n (cribbing from the Intel manual):
C3 RET Near return
CB RET Far return
C2 iw RET imm16 Near return + pop imm16 bytes
CA iw RET imm16 Far return + pop imm16 bytes
(And I think that's been true since the 8086.)
Distinguishing between near and far (e.g., ret vs. lret in AT&T or retn vs. retf with some other assemblers) makes sense, but what would a l or q suffix denote?
But more to the point, even if there's a good reason to accept retl/retq as input, is there any reason to emit it ever?
--
Stephen Checkoway
2006 Sep 19
0
Problem about rombios initializing network card''s PnP option ROM
...network card, and also want to let rombios (which is not DHA) to initialize networks card''s pnp option Rom(the pnp option rom is DHA).
however , I find the init program(offset by 3 from 55aa header signature) within option rom can not run properly ---- it cause stact underflow . and when retf form option rom ,system crash because stack corruption.
I think maybe rombios has faultiness or some other bug, I am very confused :(
Who can give me a hand , please telling me why rombios can not init my network card''s pnp option rom ,
PS :
I trace the initialization by opening the deb...
2014 Jun 29
0
SYSLINUX 6.03-pre18 crashes on Mellanox/Intel card with iPXE stack
...ES=9300 FS=93AE GS=93AE SS=93AE C=0 Z=0 D=0 I=1 S=0
>
>
>
> 9300:030E CALL FAR 0000:7C00
>
> 9300:0313 ADD SP,0004
>
> 9300:0316 RET
>
> 9300:0317 PUSHF
>
> 9300:0318 PUSH CS
>
> 9300:0319 PUSH 031F
>
> 9300:031C PUSH EAX
>
> 9300:031E RETF
>
> 9300:031F RET
>
> 9300:0320 CALL FAR WORD PTR SS:[139C]
>
> 9300:0325 RET
>
> 9300:0326 PUSHAD
>
> 9300:0328 PUSH DS
>
> 9300:0329 PUSH ES
>
> 9300:032A PUSH FS
Thanks for the details. I wonder if this might be related to some troubles
I've...
2014 Oct 07
4
[LLVMdev] Stange behavior in fp arithmetics on x86 (bug possibly)
Hello everyone.
I'm not an expert neither in llvm nor in x86 nor in IEEE standard for
floating point numbers, thus any of my following assumptions maybe wrong. If
so, I will be grateful if you clarify me what's goes wrong. But if my
guesses are correct we possibly have a bug in fp arithmetics on x86.
I have the following ir:
@g = constant i64 1
define i32 @main() {
%gval = load
2008 Nov 22
5
[RFC][PATCH] Gfxboot COMBOOT module
...cb_fread ; 2
+ dw cb_getcwd ; 3
+ dw cb_chdir ; 4
+ dw cb_readsector ; 5
+cb_len equ ($-cb_table)/2
+
+gfx_cb:
+ push cs
+ pop ds
+
+ cmp al,cb_len
+ jae gfx_cb_error
+
+ movzx bx,al
+ add bx,bx
+ call word [bx+cb_table]
+ jmp gfx_cb_end
+gfx_cb_error:
+ mov al,0ffh
+gfx_cb_end:
+ retf
+
+; Return status info
+;
+; return:
+; edx filename buffer (64 bytes)
+;
+cb_status:
+ mov edx,cs
+ shl edx,4
+ add edx,fname_buf
+
+ xor al,al
+ ret
+
+; Open file
+;
+; return:
+; al 0: ok, 1: file not found
+; ecx file length (al = 0)
+;
+cb_fopen:
+ push ds
+ pop es
+ mov ax,...
2009 Apr 05
3
[PATCH] Gfxboot COMBOOT module
...cb_fread ; 2
+ dw cb_getcwd ; 3
+ dw cb_chdir ; 4
+ dw cb_readsector ; 5
+cb_len equ ($-cb_table)/2
+
+gfx_cb:
+ push cs
+ pop ds
+
+ cmp al,cb_len
+ jae gfx_cb_error
+
+ movzx bx,al
+ add bx,bx
+ call word [bx+cb_table]
+ jmp gfx_cb_end
+gfx_cb_error:
+ mov al,0ffh
+gfx_cb_end:
+ retf
+
+; Return status info
+;
+; return:
+; edx filename buffer (64 bytes)
+;
+cb_status:
+ mov edx,cs
+ shl edx,4
+ add edx,fname_buf
+
+ xor al,al
+ ret
+
+; Open file
+;
+; return:
+; al 0: ok, 1: file not found
+; ecx file length (al = 0)
+;
+cb_fopen:
+ push ds
+ pop es
+ mov ax,...