[rant]
I have just today assembled some x86 code, my first in some many months, and it broke. Does not assemble anymore with the latest fasm version. But this is not the fault of fasm, this is the fault of Intel. Intel broke my code. They broke more than 80% of all my apps and OSes.

Explanation: Intel introduces a new instruction called crc32. Well for the longest time I have a procedure called exactly that same name. And guess what, every program that wants to compute a crc32 will include my standard library with the crc32 procedure, and guess what the error I get it:

For now I have to downgrade to an older fasm version. I don't have time to think about the best way to keep with the new opcode names and keep my function name both at the same time. I hope I don't have to go through all of my sources and replace with a new name.
[/rant]

Soo... Were here is the point that you decide to sue Intel?

Why?
Every text editor has a 'search & replace' function, so it's not hard to do that...

Or even simpler:

Sure, if I had only one file to alter, but I have thousands, literally. Plus all the copies my colleagues have, and my customers. It is no small job to change them all.

I have five options I guess.

1. only change them as I come across them. But that means I am likely to strike this problem over and over for years to come. or
2. change all now and eat the lost time. But with all the testing and stuff it is likely to produce errors. or
3. change every new version of fasm the comes out to disable the Intel crc32 instruction. But that is just ugly and cumbersome and non-standard. or
4. stick with fasm 1.67.29 forever and ever. But then miss out in all future goodies.
5. use a macro or equ or something to trick the assembler into accepting lower case crc32 for my function.

None of those options looks very appealing. I guess number 5 is the least evil.

Tomasz Grysztar: Thanks for the second suggestion (just like my number 5 I guess). But the ongoing incompatibility is going to be confusing for my customers. They will ask me why I have redefined things like that. BTW: none of the CPUs we use support the crc32 instruction yet so executing the Intel version will just cause an exception and a restart.

Let Fasm do it !

Mix solution 3+5

Your function is lowercase : crc32
Fasm accept lowercase/uppercase instruction
With Fasm You can write CRC32 or CrC32 for the intel istruction
it is ok for fasm to compile.

3: Rebuild fasm changing in TABLES.INC "crc32" to CRC32
If fasm doesent lowercase (i dont know, but why should it?) the symbol-names in TABLES.INC,
(because they are already all lowercase), the solution is almost oK and your customers
and collegues will then use "CRC32" for the Intel instruction and crc32 ,as before, for
your function, after downloading your current custom-Fasm Build.

5: in the meanwhile you redefine your crc32 as Thomasz said.
This is only intented to gain time to redistribute a macro redefinition.

The next version(/s) of Fasm, customers and collegue will download from
the standard package of fasm, that allows intel crc32, but your functionname is in the
meanwhile changed to redefined_crc32.

Is it Possible so ?

Regards,
hopcode

Massive find and replace is your best option

You'll need to tweak the regular expressions adding spaces or a comma to the end etc.

Why not code a function to iterate through your codes folder and replace all calls and function names or something alike?

I don't know if there are free alternatives but TextPipe is awesome for this kind of tasks. (hint: you can use Sandboxie or a virtual machine and when the trial period is over just restore it back )

To all those who suggest I edit all my sources, I think you are correct. This is the only really proper long term solution.

Coddy41: I wish I could, but suing Intel?! You have got to have some pretty good lawyers for that sort of thing.

hopcode: fasm converts all the source opcodes to lower case and then compares. If the opcode table has some uppercase letters then it will never be matched, basically disabling that opcode. But also probably breaking a few others due to the requirement for the binary search to have an alphabetical list to work correctly.

r22: sed is okay, but really any scripting language with regular expression could probably do some automated thing. PERL maybe?

pal: I think I will probably settle for some automated solution, but I don't have time to write a special proggy. The cmd.exe 'for' does a reasonable job of finding files in sub-folders. I can even pipe it to a text file and use that as a list of files to examine. I may have to manually cull some results depending upon the folder, since all my ARM code also uses crc32 and is not affected by Intel's choice of name. So I don't want to touch those files.

Borsuc: I like Sandboxie, and I will probably use it to do a dry run and see what gets fucked up before doing a real replacement run.

Why even consider that when he gave you a command to do it?

Because I don't run *nix.

The Sandbox would be better suited to contain all the files that store the timestamp when u run it so you can reset it back when the trial is over (if you like it and use it rarely) (I mean for TextPipe)

It has already a backup option anyway. And it can use PERL RegEx and more importantly, it is really fast with MANY files, what you are after.

I do not know what text-editor you use, but my choice is VIM (www.vim.org) and on the DOS command line you can simply do this:

I bet there even is a parameter that scans subdirectories, if you use them.

Thanks pete, as for scanning subdirs there is always 'for' in the Windows CMD.

If you are using Win32 i can write you a proggy in about 5 minutes.

Is it possible to comment out that one instructon then recompile the fasm compiler?

That was considered earlier in the thread, but it's obviously a dirty solution.

wonder when they introduce sha1sum instruction