| |
| |
| |
|
Page: 1 2 3
<looth> xarx, because "param_in_C" is declared in a C module as "int param_in_C;"
<looth> and i need to update from NASM
<looth> "mov [param_in_C], eax" would be the proper way?
<xark> looth: Yes. Its like *(¶m_in_C) = eax [which is basically param_in_C = eax].
<xark> looth: See http://nasm.sourceforge.net/doc/html/nasmdoc8.html#section-8.1.3
<looth> right
<looth> just got confused by
<looth> the fact that [] means contents of
<looth> and param_in_C is NOT a pointer.... don't get it
<xark> looth: Yeah. Its the "contents of" the immediate pointer in the instruction. :)
<xark> Hence *(&var) = eax :)
<looth> so:
<looth> "mov param_in_C, eax"
<looth> means
<looth> &var = eax?
<xark> I think thats an error... however mov eax, param_in_C will (I believe) load the address of the variable into eax.
<looth> confusing
<looth> to me
<xark> looth: The thing to remember is that symbols in asm, are the _address_ of things (since there is no type). To load the contents of a symbol, you indirect its address.
<looth> xark, oh... that cleared up a few things
<looth> why doesn't my 500 page asm book mention that...
<looth> in understandable terms
<xark> Good asm books are hard to find. :)
<looth> guess so
<looth> good brains too
<Robert> Actually, ***emblers may treat them differently.
<Robert> Some ***emblers try to simulate a kind of a type system.
<looth> nasm in this case
<looth> the macromania in MASM and TASM scared me
<xark> looth: Yes, masm ****s because it thinks it knows what you are doing. This is why masm code has "casts" all over to beat the ***embler into doing what you want (not what it guesses you want). :)
<Robert> Most infamously - masm/tasm, where mov ax,foo can do either a constant move, or a memory access (iirc).
<xark> I am ignoring that. Just stick with nasm/yasm and you will be fine. :)
<looth> yeah
<looth> haven't got to yasm yet... good?
<xark> looth: Yasm is just a "conversion" of nasm (to a better license as well as AMD64). It should be compatible AFAIK.
<looth> wonder when NASM will get beyound 0.98...
<xark> looth: nasm is fine
<xark> looth: I think its been largely abandoned to yasm.
<xark> looth: yasm has a more friendly license and active development (and supposedly much cleaner architecture).
<looth> so in the long run
<looth> nasm is not fine
<xark> looth: Well, its fine because you can seamlessly switch to yasm if need be. :)
<xark> nasm is still more widespread.
<looth> yeah
<xark> looth: Only reason I've used yasm is I wanted to goof with AMD64 code.
<xark> However, I hear nasm has some obscure bugs that can be frustrating (but I personally haven't had a problem with 0.98).
<looth> oh?
<xark> looth: 0.98 seems pretty stable. Many projects use it without issues.
<looth> right
<Robert> nasm has had some issues, yeah.. I've had it generate invalid code for me.
<Robert> At least in some versions.
<looth> 0.98?
<looth> any particular instructions? combos?
<Robert> I think not.
<Robert> And I don't remember which. :)
<looth> that's ****ed up
<xark> looth: I wouldn't worry too much about it. However, if you get a weird bug, you can always check a dis***embly to see if the code ***embled correctly.
<markos_64> well... i got file that ***embled badly in yasm but worked in nasm
<xark> markos_64: No doubt all ***emblers have some bugs...
<xark> markos_64: I hope you reported it...
<markos_64> xark: well.. i recall reporting it, but for some weird and wicked reason, i can't see it
<tgo> can someone help me with building a pe header from scratch im confused on about 2 or 3 points
<tgo> mostly Characteristics and figuring out how to map each one
<tgo> i got most of the rest done
<edcba> to map each one ?
<edcba> each one what ?
<tgo> well i dont know the word for it exactly but in olly all the olly programs i was testing had
<tgo> DW 0207 ; Characteristics = EXECUTABLE_IMAGE|RELOCS_STRIPPED|LINE_NUMS_STRIPPED|DEBUG_STRIPPED
<tgo> how did they know that those ones went with 0207
<tgo> i checked winnt.h
<tgo> but the numbers didnt match how it hought it went
<markos_64> yawn... what were the numbers?
<tgo> those are three of em
<markos_64> right. what is DEBUG_STRIPPED?
<looth> #define IMAGE_PORN 0x66
<markos_64> that's fine. what's wrong, then?
<tgo> how are those adding up to 0x07,0x02
<markos_64> 512 is 200 in hexadecimal
<markos_64> 200+1+2+4 == 207.
<tgo> ah ok
<tgo> cant believe i missed that ;\
<drocon> hmm
<drocon> anyone got any ideas
<drocon> of finding out the ranking of a website on google, for some search query
<drocon> there's probably something out there already
<drocon> if there isn't they're making me code one
<drocon> and i don't feel happy about parsing html
<illume> you can use thier api for that... if you know how to use SOAP. there are examples in lots of languages
<drocon> hmm
<lars_-> which one is suppose to be most efficient? CALLBACK_EVENT CALLBACK_FUNCTION CALLBACK_NULL CALLBACK_THREAD CALLBACK_WINDOW
<xark> lars_-: Hmm, sounds like an OS question (not an asm question).
<xark> lars_-: But of those choices, I would guess NULL is fastest, followed by FUNCTION. :)
<|isubx|> in asm can you perform an operation like: mov [val1],[val2]
<Goplat> |isubx|: no
<Goplat> you can only move from memory to and from registers, and between registers, but not directly between two memory operands
<|isubx|> can you directly transpose two values?
<|isubx|> goplat: i know u kinda already answered that but i could have sworn i read you can transpose values somehow.. maby im halucinating
<Goplat> no, xchg needs at least one register operand, just like mov
<|isubx|> k thank you very much
<illume> you can do dma transfers of memory... but not to other bits of memory I think
<markos_64> ancient DMA chips could do it
<markos_64> sadly, new chipsets don't support it
<markos_64> but there are movsb and family, so it's not big loss...
<xark> markos_64: Heh, even if they could still do it, 4.77Mhz DMA is too slow. :)
<markos_64> indeed.
<xark> I remember on ATs seeing DMA slower than CPU copy. :)
<illume> ah
<markos_64> it's still parallel, though
<xark> markos_64: Well, all the really fast busses are serial nowadays (what is old is new :)
<illume> prefetch does magic for fast copies
<xark> illume: Very CPU model specific though. I believe the Linux kernel does some benchmarks at boot to know what memcpy/checksum etc. code to use.
<illume> ah, ok
<illume> if not... they should :)
<|isubx|> is there a way to add an intiger (ecx)+(val3) and save it in edx without overwriting the values in ecx or val3?
<|isubx|> or add the two intigers in (ecx) and (val3)
<xark> |isubx|: what is val3? A value in memory?
<xark> |isubx|: I don't think you can do two indirections in one instruction on x86.
<xark> (other than movs and friends where it has input and output)
<drocon> i just gave up coding
<|isubx|> xark: ya sory was afk for a sec disreguard the ()'s
<|isubx|> val3 is a value in memory
<xark> |isubx|: I don't think you can quite do that in one x86 instruction. With lea you can add ecx and another register and put the result in edx (but I don't think you can with a value in memory - lea is about the "address").
<|isubx|> im working on a fibonacci homework ***ignment, and have been readin all day lots of different ways to do it, i have written this one becuase i havent seen anyone do it like this: http://www.rafb.net/paste/results/mq7xrK55.html
<|isubx|> ya im going to corrupt one of them but i believe i am just going to push and pop it
<|isubx|> and solve my problem.. i still need to make the printval in L3 and replace the add edx, val3 with the answer to my question
<|isubx|> probably havent seen it done like that because its so sloppy but it looks like it will work
<|isubx|> anyone know if i also need to push and pop any registers before calling WriteString?
<xark> |isubx|: What OS?
<|isubx|> winblows
<xark> |isubx|: I would ***ume standard calling conventions -> http://www.angelcode.com/dev/callconv/callconv.html\
<xark> (delete the \)
<|isubx|> thank you xark
<|isubx|> anyone able to take a look at this code and tell me if anything jumps out at you why my ChoiceThree proc is crashing? http://www.rafb.net/paste/results/spMs4b94.html
<|isubx|> from what i can tell its crashing somewhere around line 104 and the call WriteString
<sadr> hello
<|isubx|> hello sadr
<sadr> gas 2.16 rejects this: movl %ss, 0x44(%ebp)
<sadr> does it have to be movw ?
<prolific> What's %ss?
<sadr> sorry, this is i386
<sadr> so i gues it is a segment register
<prolific> Hm still never heard of it :p
<imaginator> if I recall correctly %ss isn't a "long" register
<sadr> no, it's 16-bit
<sadr> but this works with gas 2.15 however
<sadr> I wonder how it worked previously,
<imaginator> well it should be rejected, or at least warn that moving a long operand is impossible from %ss.
Return to asm
or
Go to some related
logs:
"Unable to change virtual machine power state" "Fa
poker
|
|