flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > [sug]Case insensitive MATCHIng

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


Joined: 24 Aug 2004
Posts: 17716
Location: In your JS exploiting you and your system
revolution
[sug]Case insensitive MATCHIng
In another thread there is the includeonce macro. I extended it a little to allow nested includeonce's:
Code:
macro def_includeonce{
        macro includeonce path\{
                file@include equ path
                match head path tail,files@included\\{file@include equ\\}
                match head path,files@included\\{file@include equ\\}
                match file,file@include\\{
                        files@included equ files@included path
                        def_includeonce
                        include file
                        purge includeonce
                \\}
        \}
}def_includeonce
    
And it works great.

But there is always the difficult part about agreeing with my colleagues about what case (upper or lower) must be used for the file names. Sometimes I just plain forget or maybe I have pasted in the name from explorer or for whatever reason I can end up with two names the same but with different case. So it doesn't match, the file gets included twice, and I get error messages for seemingly strange reasons.

So my suggestion is to add another directive that can do matches and ignore case. Perhaps could be called MATCHI as in match-ignore, or another name if there is a better choice. The idea is that it would be the same as the existing MATCH in every way except when matching literal strings, it would ignore any case differences.

It's use could work like this:
Code:
matchi =abc,abc {             ;<-- match/matchi here makes no difference
 display "abc=abc",13,10
}
matchi =Abc,abc {             ;<-- matchi needed here to successfully match
 display "Abc=abc",13,10
}
matchi 'xyz','xyz' {          ;<-- match/matchi here makes no difference
 display "'xyz'='xyz'",13,10
}
matchi 'Xyz','xyz' {          ;<-- matchi needed here to successfully match
 display "'Xyz'='xyz'",13,10
}

bar1 equ hello
bar2 equ hello
bar3 equ hEllo

matchi =hello,bar1 {          ;<-- match/matchi here makes no difference
 display "hello=bar1",13,10
}
matchi =Hello,bar1 {          ;<-- matchi needed here to successfully match
 display "Hello=bar1",13,10
}
matchi x,bar1 {               ;<-- match/matchi here makes no difference
 matchi =x,bar2 \{            ;<-- match/matchi here makes no difference
  display "bar1=bar2",13,10
 \}
}
matchi x,bar1 {               ;<-- match/matchi here makes no difference
 matchi =x,bar3 \{            ;<-- matchi needed here to successfully match
  display "bar1=bar3",13,10
 \}
}
    
Post 02 May 2006, 07:30
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
No matter whether it'd be a good idea or not, I'm not going to add any new directives earlier than I finish the current documentation projects.
Post 04 May 2006, 07:20
View user's profile Send private message Visit poster's website 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
No problem, it can wait, no rush, it is just a thought I had.
Post 04 May 2006, 16:21
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
imatch might be a better choice as it's similar to NASM's imacro, istruc, etc.
Post 05 May 2006, 03:51
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
But we don't have imacro and istruc either.
Post 05 May 2006, 07:57
View user's profile Send private message Visit poster's website 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
rugxulo: matchi/imatch either way seems fine by me. But let's not go too deep into the discussion until the docu's are finished.
Post 05 May 2006, 16:17
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
I just meant that since FASM shares some (minor) similarities with NASM, maybe it should stick to using the i- prefix to indicate case insensitivity. I don't need (or really want) this feature anyways. Razz

Tomasz Grysztar wrote:
But we don't have imacro and istruc either.


Obviously. Razz
Post 05 May 2006, 16:34
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
Here's me with another suggestion: "matchnum" or something like that.

Yes, I know preprocessor doesn't do calculations, but these are not calculations. It's just a matter of checking a number if it's greater than something, or lower than something, or equal.

It shouldn't be that far off the design, since "rept" already uses 'numbers'.

examples:
Code:
matchnum symbolic_constant1 <= symbolic_constant2
{ }

matchnum a > b
{ }    

It may not be useful at a first look, and things can be achieved without it, but it is much harder and overkill to do. I'm still talking about preprocessing stage here, I know assembly stage can do this, but sometimes I need it at preprocessor.
Post 05 May 2006, 17:42
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
Look here for some of the reasoning: http://board.flatassembler.net/topic.php?t=4655
Post 05 May 2006, 18:23
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
I know that Tomasz can't add anything right now but still some debate is needed for imacro I think. Suppose the following code
Code:
macro Abc{display "Hi!"}
imacro abc{display "Bye!"}
macro aBc{display "fasm"}
Abc ; (1)
aBc ; (2)    


What do you think that fasm should display at (1), "Hi!" or "Bye!"?
What about (2)? "fasm" or "Bye!"?

I vote for "Bye!" at (1) and "fasm" at (2) which in other words mean that imacro creates all the possible combinations of case-sensitive macros (macro abc, macro abC, macro aBc, ...). Of course fasm must perform this internally in another way because this way is a terrible waste of memory but the goal is to keep the behaviour as if was really happening.

PS: I forgot the other alternative I had in my mind Razz It consists in making (1) erroneous and (2) displays "fasm". In this implementation imacro purges any macro definition that insensitive matches the name and macro purges any imacro definition. I dislike this one but it seems to be easier to implement.

PS2: Supposing my first idea also a ipurge would be needed.
Post 10 Jul 2007, 04:07
View user's profile Send private message 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
Hi LocoDelAssembly,

Your idea might be useful but for now I just can't see where it could make sense. Do you have any example of a suitable use that you can share with us?

Personally I can only see this being useful in MATCH. MACRO, STRUC, PURGE and others don't seem to have any need for insensitive case matching.
Post 10 Jul 2007, 11:28
View user's profile Send private message Visit poster's website Reply with quote
dead_body



Joined: 21 Sep 2005
Posts: 187
Location: Ukraine,Kharkov
dead_body
imatch is the best idea, IMHO.

LocoDelAssembly, where do you need imacro? For what tasks?
Post 10 Jul 2007, 13:00
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
To take control over CPU instructions and assembler directives. You know, to "overload" the NOP instruction you need to do this:
Code:
irps instr, nop noP nOp nOP Nop NoP NOp NOP{
  macro instr\{...\}
}    


It would be a pain to define every CPU instruction this way, and even if you write some script that do this for you imagine how much memory would waste an instruction like PREFETCHNTA.

And as an example take a look at the assembly listing generator at macroinstruction forum, due to the lack of imacro any instruction that not have all of its characters in lowercase goes unnoticed by the generator.

About taking control over assembler directives I haven't published something about that yet (because I'm still need to finish it Razz). But when my macrosed formatter is done you'll have another example.

About istruc (which I confess it was never in my mind), perhaps deserves its insensitive version too but only because it can be used for other purposes than defining types, if the latter wasn't possible then istruc would be pointless because types should be case sensitive IMHO.
Post 10 Jul 2007, 14:17
View user's profile Send private message 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
But macro and struc are the same except that struc requires you to put a label name to declare it.

Also, why do you need complete control over an instruction? I use the mixed upper case to revert to the original instructions in two of my snippets posted to this board (compatibility macros and arm literals). Without the ability to revert to the normal instruction the macros would not be useful. I think the lower case macro name for instruction overloading is adequate. OF COURSE REAL PROGRAMMERS DON'T TYPE IN UPPERCACE, Or mIxEd CaSe, but in lower case! Wink
Post 10 Jul 2007, 16:31
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
If you want to revert to original instruction follow this.

The real life variations are all capitalized, only first letter capitalized and all lowercase. However, what about "typo errors"? I want to have a way to change behaviour without needing to modify fasm itself and since fasm allows all the unconventional combinations too I want to be able to change them as well.

I also want to propose another variant. What about having separated stacks for macro/purge and imacro/ipurge?

This idea recovers more sense with struc/istruc actually. Example
Code:
struc Message{.string rb 256}
istruc Message{.:}
.
.
.
WM_TEXT message ; WM_TEXT:
.
.
.
text Message ; text.string rb 256    


That way you define a capitalized sensitive version to define a "class" and an insensitive version to define a block. The case sensitive definition takes priority over the insensitive ones so fasm first looks up in the sensitive definitions stack and if fails then retries using the insensitive stack. This idea however must be looked carefully because since it doesn't rely on defining all combinations of macro we are really introducing new behaviour to the preprocessor which could led to unpredictible results.
Post 10 Jul 2007, 17:13
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Loco: some interesting cases:

Code:
macro xy {db 0}
imacro xy  {db 1}
xy ;db 1
Xy ;db 1    
?
in this case, we could overload original case-sensitive "xy" with case-insensitive "xy". So that would mean "imacro" would beheave just like if we had defined all case variations of name to be this macro.

Code:
imacro xy {db 0}
macro xy {db 1}
xy ;db 1
Xy ;db 0    

in this case, we will overload lowcase "xy" form, but not others.
Post 10 Jul 2007, 17:27
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
I'm aware of this situation but, what's the matter? The user must be aware that with "imacro nop" and "ipurge nop" happens this:

Code:
macro nOp{display "fasm"}
;imacro nOp{display "Hi!"}
irps name, nop noP nOp nOP Nop NoP NOp NOP{ 
  macro name\{display "Hi!"\} 
}

macro Nop {display "Bye!"}
;ipurge noP
irps name, nop noP nOp nOP Nop NoP NOp NOP{purge name}

Nop ; Displays "Hi!"
nOp; Displays "fasm"
    
Post 10 Jul 2007, 18:17
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Oh I forgot an aspect that concerns to imatch too.
Code:
imacro hernán{display "It's me Very Happy"}

hernÁn ; Should it work?

imatch ="hernÁn", "hernán"{display "It's me again"} ; Should it match?    


It's also important to specify if this will work for ASCII 7 bit only or will be able to handle locales(?).

[edit]Added missing closing quote on code[/edit


Last edited by LocoDelAssembly on 10 Jul 2007, 19:03; edited 1 time in total
Post 10 Jul 2007, 18:40
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Loco: No chance to handle locales, forget about it right now.

another interesting case is this:
Code:
imacro xxx {...}
purge xxx    

what with it?

Wink
Post 10 Jul 2007, 18:54
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
In first proposal the other 7 combinations are still available and on last proposal purge has no effect at all.

PS: And your first example with separated stacks the result is "db 0"/"db 1" and "db 1"/"db 0" respectively.
Post 10 Jul 2007, 19:13
View user's profile Send private message 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.