| |
| |
| |
|
Page: 1 2 3
Comments:
<0> ok this isn't directly related to asm either but...
<0> I have a thread which runs a tight CPU intensive loop
<0> and every 50 ms or so I want to update a label in the program to describe the status of the loop
<0> the only problem is that I can't tell how quickly or slowly the loop will run, so I can't just say every 100000 loops update the label
<0> and I don't want to use something like timeGetTime inside the loop as this will waste time
<0> any ideas how to solve this?
<1> calibrate the loop.
<1> let it run, say, 100000 times and see how much time elapses
<1> then do some math to calculate how many times will it run in 50ms.
<1> you could also recalibrate the loop each few seconds to accomodate for system load changes and the like
<0> yeah that could be solution
<0> a*
<0> another way I thought was to run the loop in a seperate thread and have it constantly output the status of the loop to a global string
<0> and use a timer to read that string every 50ms
<0> only that's very wasteful as there's lots of unecessary string copying
<0> markos_64, thought of a better solution,
<0> a timer sets a flag every 50ms
<0> whenever the loop sees this flag is set it updates the status label
<0> and then unsets the flag
<0> I haven't noticed any significant overhead of using a timer either
<2> just 'cos I think this URL will be of interest to people here:
<2> http://graphics.stanford.edu/~seander/bithacks.html
<3> I have an call r/m64 and when I call it rip is set to something other then the r/m64.. why?
<4> whatzzzzzzzz appppp azzzummmmmm
<3> is it legal to call printf on 64 bit pointers instead of 32 bit pointers?
<4> isn't that a c question? :)
<3> not when your doing it in ***embly
<3> right now gcc is generating 32 bit mov's, but I need 64 bit mov's, but I don't know if it would ignore the upper 32 bits when I called printf
<3> I'm thinking the answer should logically be yes, but I'm not sure
<4> I asked your question in c see if they are smart enough to answer it
<2> LMAO
<4> <defrost> Crazyhazy: depends on your implementation - in c99 , the printf %p format should handle all supported pointers, with modifiers, perhaps
<4> answer from c
<3> so I'll give it a shot then
<4> hope no one gets hurt in the process :P
<4> especially the innocent animals
<3> especially the innocent animals =(
<4> fur... yep... one of them got skinned
<3> how big of performance penalties are indirect jumps
<4> only one way to find out do lots of them and see the difference :)
<3> well I mean from a pratical POV they say your not supposed to do them
<3> but I'm not sure how good the prediction is nowadays.
<3> I'd expect them to use the branch prediction logic, I just don't know how much that helps for static indirect jumps
<3> err indirect calls
<4> http://gcc.gnu.org/ml/gcc-bugs/2004-05/msg00047.html something concerning indirect jumps might help might not :)
<3> Crazyhazy, imo that covers direct jump to indirect jump, not an indirect jump itself, which shouldn't screw up branch prediction
<3> otoh jump to indirect shared is definately screwing crap up
<4> lol
<3> OTOH i"m guessing the performance loss isn't too bad if your just using it to do 64 bit jumps
<4> you writing a playstation emulator? :P
<3> no why?
<4> you must be writing something that is speed critical
<4> :)
<3> yeah
<5> when values are pushed onto the stack and then popped, what order are they returned to the register in question using?
<5> i.e. if I push bytes 0x1, 0x2, 0x3, and 0x4 successively and then pop eax, will I get [0x1][0x2][0x3][0x4] in eax?
<3> stack = lifo
<5> okay
<5> thats understood
<5> but what order are the bytes stored in eax?
<3> uh, they don't get stored in eax
<3> err wait
<5> i.e. is there any byte swapping going on
<3> I would say your right
<5> I'm looking at some shellcode here and it isn't exactly clear whats going on ;P
<5> so there isn't any byte-swapping going on when coming back from memory on an x86 platform?
<3> imo no
<3> but check the intel docs to be sure
<6> hello
<6> non
<6> little-endian, thats all there is to know.
<7> [Shiba]: you can't push bytes like that...
<7> they'll get extended to 2 bytes
<8> http://verb.org.ua/2006/07/16/ia-32-instrdb-001/
<7> (at least)
<9> oh, good point
<0> is there some sort of profiler available for masm programs that can tell me where my program spends most of its time?
<7> your usual profiler can do that...
<0> really?
<0> which profiler as an example?
<0> oggis_, which profiler could I use, all the ones I can find are designed for C or C++
<7> not really
<7> most can do instruction-level instrumentation at varying levels of accuracy
<0> ok, just profiled my code using CodeAnalyst
<0> seems a lot of time is spent on the div opertation
<3> div is slow.
<10> anything that deals with fp will ****, ymmv
<0> yeah according to the opcode sheet a div mem32 costs 40 cycles
<0> well this is just using he integer divide so it's not too bad
<10> ah.
<3> errr
<3> integer divide is worse then float divide
<3> in performance
<10> on x86?
<3> im prettty sure I read that
<3> lets turn to google
<10> doesn't sound too implausible
<0> it is?
<0> hmm
<3> ah yeah
<3> I'm right.
<3> maybe.
<0> link?
<3> well I'm trying to find a link that isn't from ~1998
<0> hehe
<3> Ah right I remember the argument.
<3> Floating point runs seprately from integer so it pipelines better.
<3> I'll write a test case.
<0> The code I'm looking at is actually the mersenne twister random number generator that I think was made by one of the people at asmcommunity
<3> eh, in my completely unscientific tests where I did a for loop on x for a billion or so iterations adding 1 to x each time,
<3> if I did a floating point divide x by 5 it finished slightly faster then an integer divide
<3> on -O3
<3> (slightly means consistently .007 seconds faster, well outside of statistical error)
<3> otoh for a mersenne twister you don't have a choice.
<0> what do you mean?
<3> I mean if your dividing x/5 or x/5.0f, the floating point divide is slightly faster
<0> surely the FPU can do the same as the integer divide...
<3> Now, how much of that is pipelineing effects, I'm not sure
<0> so why couldn't I change the mersenne code to use the FPU instead of integer division
<3> because mersenne's have to have absolute values.
<3> and floating point has error
<0> I still don't get you
<3> =(
<0> this code is simply using div to get the remainder when dividing eax by a set limit (in this case 26)
<3> and if you did that with a float you'd get the wrong answer
<11> j #ubuntu
<0> hmmmm
<11> ops sorry
<11> i missed the /
<0> heh
<11> :P
<0> I suppose the FPU would give the reamainder as a floating point value
<3> That would be a resonable ***umption.
<0> you could do it with the FPU by doing an extra subtraction, and multiplication
<0> but then there's not much point in using the FPU I guess
<3> and let error crreep in and risk trashing the algorithm?
<0> yeah...
<3> thats a "bad" thing
<12> What's the difference between
<12> xor eax,eax
<12> and
<12> mov eax,0
<12> ?
<13> what's the difference between NEG and NOT?
<12> ...
<13> what?
<12> <12> What's the difference between
<12> <12> xor eax,eax
<12> <12> and
<12> <12> mov eax,0
Return to
#asm
or
Go to some related
logs:
#bash
#mysql
USB marble gpm xorg
Horuzlna
obsidian xchat symbolic link
install x11 ubuntu
#perl
how do I unhide ekiga
sound problem ubuntu asla
suse 10.1 sis 660
|
|