[sug]Case insensitive MATCHIng

Index > Compiler Internals > [sug]Case insensitive MATCHIng

Goto page 1, 2 Next

Author

Thread

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20339
Location: In your JS exploiting you and your system

revolution 02 May 2006, 07:30

[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
 \}
}

02 May 2006, 07:30

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 04 May 2006, 07:20

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.

04 May 2006, 07:20

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20339
Location: In your JS exploiting you and your system

revolution 04 May 2006, 16:21

No problem, it can wait, no rush, it is just a thought I had.

04 May 2006, 16:21

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 05 May 2006, 03:51

imatch might be a better choice as it's similar to NASM's imacro, istruc, etc.

05 May 2006, 03:51

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 05 May 2006, 07:57

But we don't have imacro and istruc either.

05 May 2006, 07:57

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20339
Location: In your JS exploiting you and your system

revolution 05 May 2006, 16:17

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.

05 May 2006, 16:17

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 05 May 2006, 16:34

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

05 May 2006, 16:34

Borsuc

Joined: 29 Dec 2005
Posts: 2465
Location: Bucharest, Romania

Borsuc 05 May 2006, 17:42

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.

05 May 2006, 17:42

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 05 May 2006, 18:23

Look here for some of the reasoning: http://board.flatassembler.net/topic.php?t=4655

05 May 2006, 18:23

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 10 Jul 2007, 04:07

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.

10 Jul 2007, 04:07

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20339
Location: In your JS exploiting you and your system

revolution 10 Jul 2007, 11:28

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.

10 Jul 2007, 11:28

dead_body

Joined: 21 Sep 2005
Posts: 187
Location: Ukraine,Kharkov

dead_body 10 Jul 2007, 13:00

imatch is the best idea, IMHO.

LocoDelAssembly, where do you need imacro? For what tasks?

10 Jul 2007, 13:00

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 10 Jul 2007, 14:17

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.

10 Jul 2007, 14:17

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20339
Location: In your JS exploiting you and your system

revolution 10 Jul 2007, 16:31

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

10 Jul 2007, 16:31

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 10 Jul 2007, 17:13

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.

10 Jul 2007, 17:13

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 10 Jul 2007, 17:27

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.

10 Jul 2007, 17:27

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 10 Jul 2007, 18:17

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"

10 Jul 2007, 18:17

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 10 Jul 2007, 18:40

Oh I forgot an aspect that concerns to imatch too.

Code:

imacro hernán{display "It's me "}

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

10 Jul 2007, 18:40

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 10 Jul 2007, 18:54

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

10 Jul 2007, 18:54

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 10 Jul 2007, 19:13

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.

10 Jul 2007, 19:13

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