| |
| |
| |
|
Page: 1 2
Comments:
<0> how would I make a messagebox? invoke MessageBox(0,"testing",0,0) ??
<1> HighNeko, which ***embler?
<1> _testing db 'testing', 0
<1> invoke MessageBoxA, 0, _testing, 0, 0
<0> Ah, thank you
<1> There may not be a ',' after MessageBoxA depending on the invoke macro
<1> Quartus, xor ax, ax makes ax 0 not 1 since each bit gets set to 0
<0> A few hours ago I read something about xor. It might help. http://en.wikipedia.org/wiki/XOR_swap_algorithm
<1> xor cycles each bit of the destination and source and if they are the same that bit in the destination gets set to 0, else 1
<2> the info I have on floating point comparison instructions is very poor. Does anyone know of better text for at&t asm ? I'd like to be able to use jg,jne,jlt,etc. on the results of fcom and ftst
<3> RedGhost, I'm clear on what xor does -- my two choices up there were to zero ax using xor and then load a byte value of one into it, or to load a 32-bit value of 1.
<2> the info I have on floating point comparison instructions is very poor. Does anyone know of better text for at&t asm ? I'd like to be able to use jg,jne,jlt,etc. on the results of fcom and ftst
<1> Quartus, if you want just a byte in AX remember that AL and AH are the Low/High (Hence L,H) bytes of AX
<1> There is always movzx aswell (:
<3> I know that too. I'm wondering which is faster in terms of cycles -- loading a 32-bit value into eax, or clearing eax and loading an 8-bit value.
<1> I have a cycles chart somewhere I think bookmarked, let me check.
<1> But on newer processors they are probably very similar.
<3> The latter is one byte shorter, so I'm hoping there's no particular performance penalty.
<1> http://home.comcast.net/%7Efbui/intel.html
<1> You can review the cycles here.
<3> Thanks.
<1> My pleasure.
<2> is floating point math always faster than integerial math? (fpu vs cpu)
<4> thats a really useful link
<1> brb
<0> What's JE do?
<3> Juggles Eggs.
<0> jump if equal?!
<3> It's what John Edwards has stamped on his luggage. Do you mean x86 ***embler?
<0> I checked google, but gave up quickly because I didn't see many things.
<0> Yes, ***embly.
<3> Google for "\ 4 constant compile-only-flag
<3> \ 8 constant interpret-only-flag
<3> gah sorry
<3> Google for x86 je opcode
<0> I'm seeing in my dissasembler thing, JE SHORT 0040E50C
<3> Seriously, do that google. The first hit is a whole bunch o' info that you'll also need.
<0> Ah, ok. I wouldnt've known how to search for that kidna thing. Thanks.
<3> Always helpful to put some supporting words when searching for something short or general.
<0> Yea, I was trying asm je lol
<3> :)
<0> 'asm je' thousands of hits!
<3> There would be.
<3> even "asm je reference" would have worked, though.
<0> INC EAX ;+1?
<2> which gdb frontend do you all recommend? ddd? insight?
<5> heyo
<6> hi
<7> 'morning
<7> have a look at http://pastebin.com/776606
<7> i have unexpected results from the c compiler
<6> yawn... multibooting, are we?
<8> hm, has asm evolved much since 99?
<6> er...
<6> maybe you forgot to #include the damn multiboot .h file?
<7> mwk, i've patched grub to boot x86_64 images
<6> OEEK?
<7> no, the problem is highlighted in the pastebin (see the ***em output)
<7> the c compiler output seems to begin the function by saving %rdi and %rsi right onto my p***ed arguments
<6> problem? what problem?
<6> rdi and rsi are saved into the locals section of cmain's stack frame.
<7> i think -88(%esp) is the address of my 1st p***ed argument!
<6> the thing that kinda escapes me is why the hell is this frame so fat... but you can't expect gcc to be reasonable without -O
<6> -88(%rbp) it is.
<6> not rsp.
<6> nor even esp.
<7> sorry, %rbp
<6> and space for locals is allocated here: subq $112, %rsp
<6> also, let me go into my standard flame mode for such cases...
<9> fafnir: the basic instruction set is exactly the same
<9> fafnir: and same registers
<7> mwk, see the cmp insn. %edi has trampled my argument
<9> fafnir: but you have SSE2/3 extensions and of course Athlon64 is completely different
<6> WHY THE HELL YOU PEOPLE DON'T LEARN THAT GCC OUTPUTS COMPLETE UNREADABLE BULL**** CODE WITHOUT P***ING -O3 -fomit-frame-pointer?
<6> mcnster: -88(%rbp) contains 'magic' parameter.
<6> mcnster: it is set to magic in line ' movq %rdi, -88(%rbp)'
<6> remember: ON x86_64 ARGUMENTS ARE P***ED IN REGISTERS.
<9> you should set fomit-frame-pointer in debugged stable code only :)
<7> and what is the value of %rdi when the fn begins?
<6> nANDy: -fomit-frame-pointer is unrelated to debugging.
<6> mcnster: first parameter is p***ed in %rdi.
<6> ok, so my second flame
<9> mwk: erm no, you can view local vars, etc, using EBP if your code crashes
<7> mwk, ok then
<9> so you could release some beta without that flag and then set it on the final release
<6> nANDy: without -fomit you can use ESP instead of EBP.
<7> (this fn is being called from ***embler code btw)
<9> mwk: yeah I know
<6> so, my flame.
<7> mwk, thank you. i didn't know x86_64 p***ed args that way
<9> but kernel dumps won't be very informative
<6> DON'T EVER TOUCH THE ***EMBLER-C PROGRAMMING WITHOUT FIRST READING THE ****ING PSABI FOR APPROPRIATE PLATFORM.
<6> nANDy: DWARF debugging format solves everything.
<6> http://x-os.homeip.net/x-os/hdir/pdf/sysv/psABI-x86_64.pdf
<7> mwk, cool. i'll have a look at it
<6> this is the document that you should've read for parameter p***ing conventions... and much more...
<6> also, if you're writing kernel code, you'll NEED to p*** -mno-red-zone to gcc. otherwise, weird ****ups will occur if your code uses interrupts.
<6> gcc manpage and that psABI explain why
<7> excellent, thanks
<7> argh, i was looking for exactly this document last night when coding x86_64 elf translations
<7> ok. back to it. later.
<8> nANDy: hm, cool, i learned it back in the mid to late nineties, and was thinking about refreshing myself
<6> take a look at itanium ***embly language. it's guaranteed to teach you something new. unless you barf before comprehending even the simplest program, that is. which is quite common, actually.
<10> this isnt really asm related, its more of a linux problem, but since im doing it for a demo im writing in asm it cant hurt to ask... does anyone know how to force linux /dev/dsp to start playing without a full buffer?
<6> *barf
<6> *
<9> fafnir: there's not much to refresh, not even from 1995 :)
<6> nANDy: itanium will refresh all your memory, and then some.
<9> fafnir: hasn't been any major changes since 386... FPU/integer/registers is all the same
<9> yeah, Itanium and Athlon64 are completely different
<9> x64
<6> yah.
<6> yet itanium has the unique property of making your mind turn into a pile of wet noodles when you read the manuals
<9> well, x86 is not _that_ much different, but the EPIC part pf Itanium is
<6> yeh.
<6> EPIC, loop register rotation, RSE... everything
<9> conditional execution flags :)
<8> neato
<8> thats a bonus
<9> well, the conditional execution is just a workaround because the engineers are too lazy to make conditional branching more effective
<9> there's no logical reason why a branch would be slower
<9> if you avoid flushing the entire pipeline at predition miss, that is
<11> every instruction on ARM is conditionally executed, so it was weird when I started using x86
<10> x86 is a horrible architecture
<10> if windows was cross-platform i dont think x86 would survive
<9> why do you think x86 is horrible?
<6> yeah... we'd all be using sparc or something
<9> it's convenient to code in x86 compared to RISC
<6> nANDy: CISC. non-uniform instruction length. segmentation. built as hack over hack over 8080.
<9> segmentation?!
<9> you've used flat memory for ages
<9> and why is non-uniform instruction length a problem=?
<6> nANDy: efficient pipeline is impossible.
<9> mwk: it's a little complicated - CISC code is more informative than RISC (like hilevel is more informative than ***embler) which gives the CPU more potential to optimize
<6> nANDy: ... as opposed to RISC code which comes out of compiler pre-optimised. CPU has to do less, so it has less transistors. it's cheaper. good thing, no?
<9> correct
<12> eip on amd64 is called what?
<6> s0ttle: rip
<9> but that's also the reason why EPIC hasn't become more popular - compiler writers don't the heavy optimization
<6> s0ttle: as in, "Rest in Peace'
<12> ah thx
<10> ill take ARM over x86 any day of the week
<10> barrel shifter and conditional execution F T W
<11> the non-uniform instruction length also freaked me out with x86 too
<6> nANDy: because they got used to modern x86 chips which effectively duplicate the optimisation logic in hardware.
<6> nANDy: icc does good job optimising for itanium
<13> nANDy: I think if Intel and AMD want to sell their chips they are going to have to contribute some code to the compiler projects
<13> They should take some optimization stuff and release it into the public domain so gcc and MS and Borland and whoever can all use it
<13> I have never understood why they don't do that
<11> bic r0,r0,r0,asr#31 ftw
Return to
#asm
or
Go to some related
logs:
vista virus intruder spyware
#css
Dreambox cron job
suse10.1 windows domain
#linux
frontcontroler design pattern
glue bison-kit
gsxr1000rr
bcmwl5.sys+driver win2k+ubuntu
#physics
|
|