Compile problem 'dword ptr'

[MajorDill]

I am trying to compile a program with approx 5000 - 6000 lines of code. My first few attempts come up with the usual syntax errors. I correct the last couple errors, expecting a perfect compile, and I get several hundred errors that look like this:

Error: 'dword ptr [AH+ebx*3]' is not a valid base/index expression

If I comment out about 2/3s of the program it seems to compile okay. Its acts like I have hit some sort of limit.

The program is pretty much straight basic, no libs. or funky stuff like accessing other programs or languages. It accepts text input and output text at a console prompt, no graphics, no complex math. I compile without any options: fbc xxx.bas

I am compiling this on linux but I will try windows tomorrow when I have access to a win7 computer.
I would rather not post the code since the ideas in it are not mine and it is really long. I know this makes it difficult, but keep in mind that it doesn't seem to matter what part of the code I comment out, it seems to be the length of code.

Thanks

[counting_pine]

I have a suspicion that an expert in x86 may take one glance at that line and tell us immediately why it doesn't work and what code might have caused the error.

But failing that, if you compile with -g -R and analyse the emitted .asm file, then using the error message you should be able to find the bad line (either with a quick search or by going to the reported line number).
Shortly before it, starting with a # sign, will be the FB line of code that resulted in the error. If you are happy to give us that line, along with the types of any variables/arrays involved, that might be helpful.

[marcov]

I have a suspicion that an expert in x86 may take one glance at that line and tell us immediately why it doesn't work and what code might have caused the error.

I'm not an "expert", but I guess that ah as a 8-bit register is simply not allowed here. It is address calculation and that is 32-bit.

What caused it is hard to say. It looks like an lookup of a field in an array of structs, but then the loopcounter would be the scaled value, not the displacement.

Anyway, some place is not checked if the incoming value is byte sized (as opposed to 32-bit word sized), or there is a real ugly bug in the peephole optimizer.

[MajorDill]

Okay, I think I figured it out. Thanks for the -g -R suggestion which provided the code to debug this.

I do a DIM SHARED AS INTEGER aV(9) at the beginning of my program (one of several arrays)
When I code a function that tries to access this (ex. xField = aV(9)) the compiler pops out an assembler error.
If I change it to aV() and redim it in the program to 9, the functions seems to like it better...I don't know why... I'm
chalking it up to coding feng shui.

[fxm]

Have you tried to compile your program with option -exx

[dodicat]

Freebasic can compile many thousands of lines, I've tried it with bitmap pixel position and colours set as data, 60,000 lines no problem.
LInux does this often, you must change variable names, the error gives you a clue to the variable you must change.
Have you AH as a variable name for example?

[counting_pine]

If that's the problem, hopefully the problem should be workaroundable with a simple find/replace, or alternatively put "#define AH _AH" or something at the top of your code, which would cause the variable to be renamed internally.

[codeFoil]

Error: 'dword ptr [AH+ebx*3]' is not a valid base/index expression

If you have not already followed counting_pine's advice, please compile with the -R -g options.
Open the resulting .asm file and search for that "[AH+ebx*3]" and post the five lines before and after.

That expression definitely indicates a compiler bug. I don't know if Gas performs any magic tricks, but the AH+ebx is definitely invalid code, and the *3 is illegal as well.
It looks like a glitch in an optimized calculation, and I wouldn't be surprised it was occurring as an operand to a LEA instruction being used to do a trick multiplication.

[marcov]

Error: 'dword ptr [AH+ebx*3]' is not a valid base/index expression

If you have not already followed counting_pine's advice, please compile with the -R -g options.
Open the resulting .asm file and search for that "[AH+ebx*3]" and post the five lines before and after.

That expression definitely indicates a compiler bug. I don't know if Gas performs any magic tricks, but the AH+ebx is definitely invalid code, and the *3 is illegal as well.
It looks like a glitch in an optimized calculation, and I wouldn't be surprised it was occurring as an operand to a LEA instruction being used to do a trick multiplication.

I think Counting Pine meant to say that it is probably a "ah variable" vs "ah register name" naming conflict.

So it should be a 3 element array starting from SYMBOL/Variable AH.

But since AH Is reserved in assembler, the assembler reads it as "3 element array starting from register AH".

The macro trickery suggested by Counting Pine replaces all uses of the variable with its underscore prefixed equivalent. If the preprocessor is smart enough to not touch the assembler, that could work.

[counting_pine]

Yeah, it's - more or less - a straight text substitution.
This code:

Code: Select all

#define ah ah_
dim ah as integer
ah = 1
print ah

is effectively equivalent to this:

Code: Select all

dim ah_ as integer
ah_ = 1
print ah_

Because the variable, internally, is called AH_, it does not get confused with AH.
FB defaults to uppercase internally for variable names, so I suspect that AH does represent a variable rather than an attempt at using the 'ah' register.

I missed the post about "ex. xField = aV(9)". If you could post the type information for "ex" that would be helpful. Maybe it will be possible to compile a short example code. But if you could follow the advice in codeFoil's post and give us the five lines of asm as well, that might be helpful. And also it would be good to know whether it works in Windows, although I suspect given the *3, perhaps not.

If it's also a faulty optimisation, it would be interesting to look into it. Though it doesn't seem likely for two independent errors to occur on one asm line..

[yevrowl]

This guide helped — viewtopic.php?t=27851