| |
| |
| |
|
Page: 1 2
<looth> howdy
<looth> i have a NASM routine that i'm calling from C. It has one parameter.
<looth> which is pushed on the stack.
<looth> Can I refer to it like this:
<looth> [esp+4]
<looth> ?
<looth> Without setting up a stack frame?
<looth> Just need it to be as fast as possible
<markos_64> you can.
<markos_64> although it can confuse debugger, profilers and all other stack unwinders
<markos_64> maybe even c++ exception handling -- not sure
<looth> markos_64, that's fine as it's kernel code
<looth> markos_64, alas, the code hangs with or without stack frame
<looth> could you take a look?
<markos_64> okay
<looth> http://pastebin.com/393933
<looth> when I call spinLock, the computer just hangs
<looth> I call it like this from C:
<looth> static uint32_t lock;
<looth> spinLock(&lock);
<looth> ah, I also set lock=0; before calling spinLock(&lock);
<markos_64> yawn
<markos_64> now, tell me what is "[ebp+8]"?
<markos_64> [ebp+8] is ADDRESS of the lock
<markos_64> not the lock itself
<looth> it is?
<looth> so I need to:
<markos_64> mov ecx, [ebp+8]
<looth> mov ebx, [ebp+8]
<markos_64> no, use ecx
<looth> and then [ecx]
<looth> ?
<looth> and then [ecx]
<markos_64> because ebx has to be saved
<markos_64> yes
<markos_64> this should fix the problem
<looth> ebxhas to be saved?
<markos_64> yes
<markos_64> becaause that's c calling convention
<looth> oh
<looth> return param?
<markos_64> hmm?
<looth> it's a shame NASM doesn't have [[ebp+8]] syntax then
<looth> anyway, thanks.
<markos_64> it's not NASM's fault
<looth> i'll try your suggestion now
<markos_64> it's lack of this addressing mode in x86 processors
<looth> right
<xark> looth: This page may be helpful -> http://www.angelcode.com/dev/callconv/callconv.html
<looth> AND IT WOOOOOOOOOOOOOOOOOOOORKS!
<markos_64> hehe
<looth> damn, i cannot even begin to tell how n00b i am
<looth> wonder... if I put a LOCK statement in front of the xchg, will this work even on SMP?
<looth> or do I need to lock the bus for each statement and turn off interrupts?
<markos_64> xchg is ALWAYS locked, anyway
<looth> ah
<looth> xark, thanks for the link
<markos_64> so it works on SMP already.
<looth> nice... it's why I need the spinlock in the first place :-)
<xark> markos_64: Hello. I am curious, what kind of "64" are you? :)
<looth> amd?
<xark> looth: That would be my guess (or EMT64), but I wanted to check if it was something more exotic. :)
<looth> really old hacker?
<xark> looth: Huh? What are you asking?
<looth> Mark Os, 64 years old
<xark> Hehe. Ah, I suppose, but I was thinking it could also be MIPS, IA64, PPC etc. :)
<looth> GeriatricOS
<xark> I hope I am still twiddling bits at that age (more than halfway there). :)
<looth> nah, I'm gonna give up at 40
<archivist_> aI have a geratric 64 bit with debian Alpha
<looth> do something else
<looth> archivist, debian???
<archivist_> yup
<xark> I think I ran RH 5 or somesuch on it...
<archivist_> hehe the alpha is to heavy to put in the attic
<archivist_> I need another cpu board to fill it
<xark> archivist: Is it still daily operation?
<xark> ^in
<archivist_> no its not reliable on the networking side. I use it at home as a C development box. I should put the latest debian on it to see if that fixes it
<archivist_> the problem could also be the winbox at home w2k sp3
<Inside> Yo!
<Robert> Hey.
<Robert> Acid. >:)
<Inside> o_o
<Inside> E..h?
<Robert> You probably want a paper/book on computer design.
<Inside> Well, I don't want something too hard either O_o.
<Robert> Hmm...
<Inside> Like.. theory, I guess :p
<Robert> So, you want to understand the most complex invention ever, but it shouldn't be too hard? Hmm...
<Inside> "The electron p***es from point a to point b... value is added.."
<Robert> Can you read German?
<Inside> no >_>
<Robert> OK. Then I'll keep looking.
<Inside> Well, what I mean is I don't want to read up on the newer processor with their newfangled caches and advanced techniques to squeeze bits out :p
<Inside> Thanks ^_^
<Inside> I'm googling too, but I can't really see anything.
<Robert> http://www.play-hookey.com/ - this has info on digital electronics.
<imaginator> why is it that xchg is an atomic instruction with SMP? does this mean that it should be avoided if a non-atomic exchange is needed?
<xark> Hmm, well the nasm doc say: XCHG exchanges the values in its two operands. It can be used with a LOCK prefix for purposes of multi-processor synchronisation.
<xark> I think its fine to use (but don't add prefix if its unneeded).
<edcba> yes it can but there is an implicit lock :)
<xark> edcba: Interesting.
<xark> edcba: Was it always this way, or is this a feature of newer CPUs?
<edcba> i think it appeared with pentiums
<edcba> dunno where i did read that
<imaginator> "The operands can be two general-purpose registers or a register and a memory location. If a memory operand is referenced, the processor's locking protocol is automatically implemented for the duration of the exchange operation, regardless of the presence or absence of the LOCK prefix or of the value of the IOPL."
<xark> imaginator: What is that from?
<imaginator> so I guess I should avoid it for performance in critical parts
<imaginator> xark: the Intel instruction set manual
<edcba> always a good read :)
<DarkMorph> can someone tell me how to move a qword value onto the stack? (x86 asm) I tried: sub esp, 8; mov [esp], qword [x] and nasm gives an error
<edcba> you can't mov memory to memory
<xark> movs ? :)
<edcba> yes of course :)
<xark> edcba: But I agree with the spirit of your statement. :)
<DarkMorph> I was taught you can't just push qword [x] because push is a 32-bit op and qwords are 64-bit >_> I can't recall how the guy mov'd the 64-bit value onto the stack
<edcba> twos push maybe :)
<imaginator> DarkMorph: move the qword [x] into a register, and then move into into [esp]
<DarkMorph> I'm trying to use fldpi and move that value from the floating-point stack to memory, then to the stack so I can call printf
<DarkMorph> I can't put [x] into a register, a register is just 32-bit
<imaginator> oh
<wcstok> get a 64 bit machine :P
<DarkMorph> I used sub esp, 8 to "make room" on the stack for 8 bytes
<DarkMorph> that's not a solution
<DarkMorph> fldpi puts pi on st(0), I move that to memory (I called it x) I need to move the value of x (pi itself) to the stack so I can call printf
<imaginator> the quadword code that I've worked with (long longs/uint64_t) has done it using at least 2 instructions, so one set for the lower dworrd and another for the upper dword.
<DarkMorph> oh.. I can use dword [x] and dword [x+4] ?
<DarkMorph> hmm, let me try that! :)
<DarkMorph> whoa, I got really crazy output and a segfault, I'm doing something wrong.. I tried using two push's... using mov [esp], dword [x] gave me an error on ***embly, op size not specified
<DarkMorph> okay hang on... I got it, I just have to fix this segfault, heh
<Inside> Pffft, real men use C++
<Inside> Actually, sorry, real men use flash for all their coding needs.
<imaginator> Inside: so what is an unreal "man?"
<imaginator> :)
<Inside> Well..
<Inside> unman -> undead -> zombie
<Inside> -> asm programmer
<|isubx|> its a full house in here tonight
<Ryugi> hello
<Robert> Hi.
<Ryugi> what is a good book to learn ASM from
<Robert> I really wish I knew.
<Robert> Because people ask that a lot.
Return to asm
or
Go to some related
logs:
rock
politics
|
|