| |
| |
| |
|
<aFlag> i've tried unununium also
<aFlag> i wasn't able to do anything useful with it though
<Lusitanian> hello
<CaffeiniaNervosa> Hey, Imaginator... sorry. I forgot I was still on here.
<CaffeiniaNervosa> What's it like?
<enot> hello! Anybody has plays minix here? #minix is silent
<enot> s/has//
<joshux> not me
<iojkl> hello
<eedy31> plop
<Nach> Does anyone here have experience of writing x86-64 inline ***embly in GCC?
<undesktop> Nach: it's the same like in x86 32 bits
<Nach> undesktop, well, I get errors that stuff like pushal/pushad is unknown unless I use -m32
<undesktop> it isn't there in x86-64
<Nach> is there a replacement?
<undesktop> AFAIK no
<undesktop> you have to push/pop all registers for yourself
<Nach> undesktop, so if the code I'm using only uses x86-32 instructions (and MMX, SSE, 3DNow) do I have to worry about pushing the new x86-64 registers?
<Nach> meaning I don't know what registers will be used, but definitly not the new ones
<Nach> unless MMX stuff uses the new ones or something
<undesktop> if you don't use registers, you don't have to safe them, that seems logic
<Nach> true, but I don't know what overlaps
<Nach> does any of the extra instruction sets now find their way into the new ones at all?
<eedy31> under gcc it's the AT&T asm synthax
<undesktop> extra instruction set?
<undesktop> what's that
<undesktop> ?
<eedy31> movl %eax,%ebx
<Nach> MMX, SSE, 3DNow, etc...
<eedy31> and masm : mov ebx,eax
<undesktop> Nach: of course they continue to exist in x86-64
<undesktop> Nach: at least for MMX, the number of registers was even doubled
<Nach> undesktop, yes, but that wasn't my question, my question is do they use the new registers at all
<undesktop> I guess yes (why shouldn't they)
<Nach> because they didn't when they were invented
<Nach> Anyone happen to know if GCC #defines something when in 64 bit mode?
<eedy31> or code a lib under an asm compilator that support 64 bits mode
<eedy31> an add it to you C source
<BlackOS> Anyone have success building gcc to generate 32 bit code on an Athlon64? (asm-inline)
<Nach> BlackOS, -m32
<BlackOS> it works
<BlackOS> but
<BlackOS> ld: warning: i386 architecture of input file `main.o' is incompatible with i386:x86-64 output
<BlackOS> how can i not have this "warnings" ?
<BlackOS> these
<Nach> BlackOS, for compiling everywhile and linking, you have to use -m32
<Nach> compiling everything*
<BlackOS> if i do: ld -m32 gcc doesn't give me warning but:
<BlackOS> ld: unrecognised emulation mode: 32
<BlackOS> Supported emulations: elf_x86_64 elf_i386 i386linux
<BlackOS> make: *** [all] Error 1
<rwt> Check manual.
<BlackOS> GNU ld version 2.15
<BlackOS> what do i have to check ?
<Nach> strange...
<rwt> BlackOS: Switch which you are using.
<Nach> you can try -mi386linux on link I guess...
<BlackOS> thank you very much Nach ;)... Now works everything ;)
<undesktop> links with gcc
<undesktop> gcc will p*** the correct flags to ld
<undesktop> gcc -m32 ...ofiles... -oexe
<BlackOS> i have: CFLAGS = -fomit-frame-pointer -O -nostdlib -march=k8 -nostdinc -nostdlib -fno-builtin -m32 -I./include
<mmiikkee12> anyone know what the asm code is to make the computer beep?
<Bluelive> so does eax become eeax or eaxx in 64bit ? :)
<midnite__> rax
<libero> rax!!
<undesktop> rax krax
<Malebranche> hello
<Robert_W_> Hi
<Malebranche> bye
<eille-la> hi
<eille-la> http://home.comcast.net/~fbui/intel/x.html#xor << it is said that the ZeroFlag is changed upon result, but how do I know why it is changed if it change?
<wobster> huh?
<wobster> it's changed, when the result is 0
<wobster> that's the purpose of CF
<wobster> ZF
<wobster> sorry
<eille-la> so, for the ZF to be set to 1 after a xor operation, the two operands had to be the same?
<eille-la> have the same value i mean
<wobster> yes
<eille-la> ok thanks
Return to asm
or
Go to some related
logs:
politics
wordpress
|
|