flat assembler
Message board for the users of flat assembler.

Index > Main > which will use less RAM - HLL macros or plain assembly

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
0.1



Joined: 24 Jul 2007
Posts: 474
Location: India
0.1
When I write a program using HLL macros of fasm, then my source file definitely
appears shorter that it would if I had written it in pure assembly.
eg:
Code:
; HLL macros.
invoke MessageBox,[hwnd], msg, cap, MB_OK

; Pure assembly.
push MB_OK
push cap
push msg
push [hwnd]
call [MessageBox]
    

So in which case does fasm uses more RAM (to compile my source) ?

_________________
Code:
 o__=-
 )
(\
 /\  
    
Post 07 Dec 2007, 04:36
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
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.
Post 07 Dec 2007, 04:46
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
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!
Post 07 Dec 2007, 06:44
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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!
Post 07 Dec 2007, 10:15
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
0.1



Joined: 24 Jul 2007
Posts: 474
Location: India
0.1
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__=-
 )
(\
 /\  
    
Post 07 Dec 2007, 10:21
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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)
Post 07 Dec 2007, 10:37
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
0.1



Joined: 24 Jul 2007
Posts: 474
Location: India
0.1
i was saying: "based on source file size"
i have 1024mb ram Smile
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 Sad
although while writing this i have 400mb free. but if i just run MSVS .NET Shocked and open MSDN help along with it.
Smile

_________________
Code:
 o__=-
 )
(\
 /\  
    
Post 07 Dec 2007, 10:42
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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.
Post 07 Dec 2007, 10:51
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17716
Location: In your JS exploiting you and your system
revolution
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.
Post 07 Dec 2007, 14:23
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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.
Post 07 Dec 2007, 14:31
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17716
Location: In your JS exploiting you and your system
revolution
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.
Post 07 Dec 2007, 14:56
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
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."
Post 07 Dec 2007, 20:38
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
if you meant at runtime, then it is *a bit* slower and *a bit* larger code, but practically it only matters in innermost routines.
Post 07 Dec 2007, 20:47
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
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.
Post 07 Dec 2007, 20:55
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
because "pushd" is not same "push", and because "invoke" isn't only HLL macro Razz
Post 07 Dec 2007, 21:03
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
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 Razz


What else is it? Looks like a macro to me. If you mean if and endif, i don't see anything really assembled there...
Post 07 Dec 2007, 21:27
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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\
Post 07 Dec 2007, 21:47
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
vid wrote:
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:
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:
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\


I thought we were talking about invoke, though...
Post 07 Dec 2007, 21:52
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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
Post 07 Dec 2007, 22:15
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1159
Azu
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.
Post 31 Jul 2009, 06:49
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.