Index
> Main > which will use less RAM - HLL macros or plain assemblyGoto page 1, 2 Next |
| Author |
|
|
edfed 07 Dec 2007, 04:46
invoke use more ram, it's logic.
the ram needed to interpret the invoke name, plus the ram used to interpret the macro ( who is assembly source ), plus the ram finally used to assemble the result in the output file. with the pure assembly source code, you just use the ram to interpret the instructions and convert them to the output file. |
|||
07 Dec 2007, 04:46 |
|
|
edfed 07 Dec 2007, 06:44
but for very big macros, it can be memory efficient.
only one macro to decode for a little source code. like : Code: macro vrybigmacro {macro of many lines} .... mov eax,10 ror [edi+412],10 shr al,8 etc.... verybigmacro verybigmacro .... i think in this case, the macromechanism operate like a compression, exactlly as call improve the code repeat. i'm sorry, i'm the one who reply and it surelly doesn't help you anymore good night baby! |
|||
|
07 Dec 2007, 06:44 |
|
|
vid 07 Dec 2007, 10:15
HLL naturally takes more RAM. Macros are preprocessed to pure assembly anyway, and only then source is assembleed.
edfed: your second post is nonsense. You DON'T KNOW how fasm macromechanism works, so please don't spread stuff which you are just quessing as fact! |
|||
|
07 Dec 2007, 10:15 |
|
|
0.1 07 Dec 2007, 10:21
thanks edfed! thanks vid!
while reading fasm source code i was somehow misguided into thinking that fasm allocates ram before hand based on file size. which was naturally less in case of HLL macros. _________________ Code: o__=- ) (\ /\ |
|||
|
07 Dec 2007, 10:21 |
|
|
vid 07 Dec 2007, 10:37
0.1: FASM allocates memory before hand, yes. You can control it from command line using -m switch.
But in most cases, just don't care (unless you have machine with 16MB RAM) |
|||
|
07 Dec 2007, 10:37 |
|
|
0.1 07 Dec 2007, 10:42
i was saying: "based on source file size"
i have 1024mb ram 
XP uses 256mb or something. explorer uses 40mb or something. firewall software, iexplorer, YIM and plenty other apps. and i am again left with small amount of memory 
although while writing this i have 400mb free. but if i just run MSVS .NET  and open MSDN help along with it.
_________________ Code: o__=- ) (\ /\ |
|||
|
07 Dec 2007, 10:42 |
|
|
vid 07 Dec 2007, 10:51
0.1: unless your source is heavy-macroed, or loads many headers, you'll hardly need more than 16MB for FASM. I doubt it is based on source file.
|
|||
|
07 Dec 2007, 10:51 |
|
|
revolution 07 Dec 2007, 14:23
My programs routinely use 200meg when compiling[1]. I'm a heavy macro user so I know my RAM requirements are going to be big. Indeed I have had to alter my macros on two occasions to use less RAM when expanding because I ran out of memory when compiling.
[1] I proved this by reducing the allocated space with the -m switch. |
|||
|
07 Dec 2007, 14:23 |
|
|
vid 07 Dec 2007, 14:31
revolution: I believe you can alter macros to save even more RAM. 200MB is really really much. Try to post some most RAM-eating macros to new thread, and we can think about optimizing them.
|
|||
|
07 Dec 2007, 14:31 |
|
|
revolution 07 Dec 2007, 14:56
vid: haha, a challenge for the folks here eh? Okay, let me think about what would be interesting and fun to optimise and I'll put 'em here.
|
|||
|
07 Dec 2007, 14:56 |
|
|
kohlrak 07 Dec 2007, 20:38
I think 0.1 means runtime not compile time... Well, normally HL code is slower than LL code. This is the same as runtime. Though, you really have nothing to gain from doing it the hardway when invoke does the same thing anyway when it comes to runtime, because the macro is like a copy and paste feature. The extra ram needed is only during "compile time."
|
|||
|
07 Dec 2007, 20:38 |
|
|
vid 07 Dec 2007, 20:47
if you meant at runtime, then it is *a bit* slower and *a bit* larger code, but practically it only matters in innermost routines.
|
|||
|
07 Dec 2007, 20:47 |
|
|
kohlrak 07 Dec 2007, 20:55
vid wrote: if you meant at runtime, then it is *a bit* slower and *a bit* larger code, but practically it only matters in innermost routines. Code: macro invoke proc,[arg] ; indirectly call STDCALL procedure { common if ~ arg eq reverse pushd arg common end if call [proc] } I can't really see any of that actually being assembled accept "push [arg]" and "call [proc]." I really don't see how it would be "*a bit*" different. |
|||
|
07 Dec 2007, 20:55 |
|
|
vid 07 Dec 2007, 21:03
because "pushd" is not same "push", and because "invoke" isn't only HLL macro
 |
|||
|
07 Dec 2007, 21:03 |
|
|
kohlrak 07 Dec 2007, 21:27
vid wrote: because "pushd" is not same "push" Actually... Come to think of it, it should give an error if you send a word through that (since a word is not a dword), in which case some amendments would have to be made to push the smaller values. Thefore, anything that you wouldn't push with that size anyway throws an error. Try it once. Code: testy dw 4h pushd [testy] Quote: , and because "invoke" isn't only HLL macro What else is it? Looks like a macro to me. If you mean if and endif, i don't see anything really assembled there... |
|||
|
07 Dec 2007, 21:27 |
|
|
vid 07 Dec 2007, 21:47
Quote: Actually... Come to think of it, it should give an error if you send a word through that (since a word is not a dword), in which case some amendments would have to be made to push the smaller values. Thefore, anything that you wouldn't push with that size anyway throws an error. Try it once. Rather than talking about things you don't understand again, look at what "pushd" macro can do. I wasn't talking about words at all. Quote: What else is it? Looks like a macro to me. i mean that there are other HLL macros, not that invoke is something else besides macro. Quote: If you mean if and endif, i don't see anything really assembled there... i meant other things in FASM\INCLUDE\MACRO\ |
|||
|
07 Dec 2007, 21:47 |
|
|
kohlrak 07 Dec 2007, 21:52
vid wrote:
Quote: pushw and pushd mnemonics force assembler to generate 16-bit or 32-bit code without forcing it to use the longer form of instruction. What else can it do? Quote:
I thought we were talking about invoke, though... |
|||
|
07 Dec 2007, 21:52 |
|
|
vid 07 Dec 2007, 22:15
Quote: What else can it do? lot of things - just look at it's definition(s), or at description of win32 macros Quote: I thought we were talking about invoke, though... no, we were talking about HLL macros: 0.1 wrote: When I write a program using HLL macros of fasm [...] vid wrote: "invoke" isn't only HLL macro |
|||
|
07 Dec 2007, 22:15 |
|
|
Azu 31 Jul 2009, 06:49
kohlrak wrote: I really don't see how it would be "*a bit*" different. So you can make this piece of code using the HLL macros (e.g. invoke) without the output being different at all? Code: xor eax,eax lodsb test eax,eax jz importEnd push esi add esi,eax push importLoop jmp fword[LoadLibraryA] Please show me. |
|||
|
31 Jul 2009, 06:49 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|