Compile problem 'dword ptr'
Compile problem 'dword ptr'
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
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
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: Compile problem 'dword ptr'
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.
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.
Re: Compile problem 'dword ptr'
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.counting_pine wrote: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.
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.
Re: Compile problem 'dword ptr'
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.
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.
Re: Compile problem 'dword ptr'
Have you tried to compile your program with option -exx
Re: Compile problem 'dword ptr'
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?
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?
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: Compile problem 'dword ptr'
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.
Re: Compile problem 'dword ptr'
If you have not already followed counting_pine's advice, please compile with the -R -g options.MajorDill wrote: Error: 'dword ptr [AH+ebx*3]' is not a valid base/index expression
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.
Re: Compile problem 'dword ptr'
I think Counting Pine meant to say that it is probably a "ah variable" vs "ah register name" naming conflict.codeFoil wrote:If you have not already followed counting_pine's advice, please compile with the -R -g options.MajorDill wrote: Error: 'dword ptr [AH+ebx*3]' is not a valid base/index expression
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.
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.
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: Compile problem 'dword ptr'
Yeah, it's - more or less - a straight text substitution.
This code:
is effectively equivalent to this:
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..
This code:
Code: Select all
#define ah ah_
dim ah as integer
ah = 1
print ah
Code: Select all
dim ah_ as integer
ah_ = 1
print 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..