flat assembler
Message board for the users of flat assembler.

Index > Macroinstructions > big endian macros

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20665
Location: In your JS exploiting you and your system
revolution 09 Nov 2008, 13:37
baldr wrote:
Code:
        dd      dword 1.0    
give "invalid argument" error?
Yes, because your expansion of "value = dword op" will give "value = dword dword 1.0"
baldr wrote:
revolution,

That label will be typeless, as Tomasz noted.
Yep, that is why I said that it didn't matter for this discussion. I was just noting an alternative for people if that is what they needed for some piece of code.
Post 09 Nov 2008, 13:37
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 09 Nov 2008, 13:52
revolution,

My question was about inconsistent handling of dword 1.0 in bare fasm, not heavily macro'ed one. Out of context, mea maxima culpa. Wink
Post 09 Nov 2008, 13:52
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8428
Location: Kraków, Poland
Tomasz Grysztar 09 Nov 2008, 13:57
Still, what revolution said contains also some truth about bare fasm. Wink Because DD already contains DWORD cast, so to write "x dd dword 1.0" is a bit like writing "x = dword dword 1.0".
Post 09 Nov 2008, 13:57
View user's profile Send private message Visit poster's website Reply with quote
wht36



Joined: 18 Sep 2005
Posts: 106
wht36 09 Nov 2008, 14:01
baldr wrote:
Your macro definition use implicit forward, may explicit common be of some use?

Code:
macro dd [op] { 
  common
    big_endian dd op
}    

Is this what you mean? Would there be a difference when there is only one line of instruction?
Post 09 Nov 2008, 14:01
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4623
Location: Argentina
LocoDelAssembly 09 Nov 2008, 14:43
Seems there was some confusion when I've said ".:", I meant this:
Code:
struc PascalStr [string]{
common
local size
.:
  db size
forward
  db string
common
  size = $ - . - 1
}

string PascalStr "Hello World", " Very Happy"  
    


Now I also understand what could was my problem, by not defining ".:" the "size = $ - ." throws "Error: Undefined symbol 'string'". Since almost every time I use a struc I use the . label for something I ended up believing that it was always needed to be defined.

Anyway seems that it was recommended to use the dot anyway because of the label type Smile

Code:
struc dd [arg] {common dd arg}
struc dw [arg] {common . dw arg}

a dd 0
b dw 0

mov ax, [a] ; accepted
mov eax, [b] ; Rejected -> "Error: Operand sizes do not match."    
Post 09 Nov 2008, 14:43
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 09 Nov 2008, 15:15
wht36,

The difference is one big_endian macro invokation vs. possibly several of them for each dd macro argument.
Code:
;macro big_endian defined somewhere above
macro dd [op] { common big_endian dd op }
        dd 1.0,2.0,3.0; dd will expand to
;       big_endian dd 1.0,2.0,3.0
macro dd [op] { big_endian dd op }
        dd 1.0,2.0,3.0; dd will expand to
;       big_endian dd 1.0
;       big_endian dd 2.0
;       big_endian dd 3.0    
Post 09 Nov 2008, 15:15
View user's profile Send private message Reply with quote
wht36



Joined: 18 Sep 2005
Posts: 106
wht36 09 Nov 2008, 17:36
baldr wrote:
wht36,

The difference is one big_endian macro invokation vs. possibly several of them for each dd macro argument.
Code:
;macro big_endian defined somewhere above
macro dd [op] { common big_endian dd op }
        dd 1.0,2.0,3.0; dd will expand to
;       big_endian dd 1.0,2.0,3.0
macro dd [op] { big_endian dd op }
        dd 1.0,2.0,3.0; dd will expand to
;       big_endian dd 1.0
;       big_endian dd 2.0
;       big_endian dd 3.0    


I see Smile Thank you very much. It seems better to use common then.
Post 09 Nov 2008, 17:36
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 09 Nov 2008, 18:22
LocoDelAssembly,

common/forward issue again?
Code:
struc PascalStr [string] {
common local ..size
.       db      ..size
        db      string
..size = $ - . - 1
}

hello_str PascalStr "Hello, World!", 7, 13, 10, " Wink", 13, 10    
looks simpler, at least if you don't want to process each struc parameter in specific way… BTW, it's my inclination to that, or double-dot macro locals are blessing? I mean, they will not break single-dot labels' attachment...
Post 09 Nov 2008, 18:22
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4623
Location: Argentina
LocoDelAssembly 09 Nov 2008, 18:32
Quote:

I mean, they will not break single-dot labels' attachment...

Assembly layer variables does not affect scope.

Quote:

common/forward issue again?


Perhaps my "db" is a macro/struc that does not accept multiple arguments Wink But yeah, of course it is easier (and there are some posts of mine that are very near to your implementation).
Post 09 Nov 2008, 18:32
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 09 Nov 2008, 18:55
LocoDelAssembly,

I mean more generic case, when you have to define labels with unique names for each macro invocation.

struc w/o label? Teach me, I need it badly! Wink
Post 09 Nov 2008, 18:55
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< 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-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.