Zeki Yasar wrote:
Can you please read below and provide us with some insight on how we could modify our process to assemble on a 64bit platform?
I have read this but didn't see much info about what those
'Intellistore machines' where the problem happens are :-(
From: Jithendra Madala [mailto:madala@xxxxxxxx]
We usually build our design in 32bit mode (using 32bit versions of
tools and gcc/3.3.6) even on a 64bit machine by default. Only if
required we build in 64bit mode using 64bit version of tools including
gcc (gcc64/3.3.2).
There are quite many "64-bit" architectures, maybe 'mips.com' uses those
'mips64' based ones?
I see a lot of search results for people having similar issues on x86_64, if x86 is specified it looks like its trying it compile in some i32 assembly optimizations that don't work on x86_64.
So "similar" things are happening with the 64-bit AMD and Intel CPU
based machines....
madala@mipscs177: 57 uname -a
Linux mipscs177 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686
i686 i386 GNU/Linux
This then is a 32-bit x86 CPU-based machine....
I get assembler errors (see below) when I do a simple gcc build. It
happens only on Intellistore machines. I tried atleast 6 machines and on
all of them gave the same error message. When I run on Rackables or my
desktop the compilation goes fine. I need immediate help on this.
gcc -DDEBUG -D_DEBUG -DXA_DEBUG=1 -DMTI_Model64 -DMIPS_SIM_TYPE_vcs
-Wall -Wno-unused -g2 -O0
-I/mips/proj/tools/vcs/vcs2006.06-SP1-4/include -I/usr/local/include
-Iinclude -I../Devices/include -I../EJTAP/include -I../MIPSInt/include
-I../Systems/Topaz1pSystem/include -c -o assert.o src/assert.c
/usr/tmp/ccEITBbp.s: Assembler messages:
/usr/tmp/ccEITBbp.s:45: Error: suffix or operands invalid for `push'
/usr/tmp/ccEITBbp.s:100: Error: suffix or operands invalid for `push'
/usr/tmp/ccEITBbp.s:150: Error: suffix or operands invalid for `push'
/usr/tmp/ccEITBbp.s:235: Error: suffix or operands invalid for `jmp'
In those x86_64 cases the reasons were obvious: There were 32-bit
'inline asm' instructions embedded
into those C programs, so the programs were "x86 specific" and compiling
them for instance for 'x86_64'
of course failed. Just as well they would have failed if trying to
compile them for PPC, MIPS, ia64, ARM
etc. other CPU based machines...
The program in question here might be something for some MIPS-simulator
("MIPS_SIM_TYPE_vcs")
and it being optimized for some x86-based machine which has a TNT2-based
graphics card (MTI Model64)...
Here the given info was limited below all the usual required minimum?
Like :
- on what kind of machine the problem happens (What CPU?)
- can the GCC in question create also 32-bit code? (Every GCC for
x86_64 as default should do this with
the '-m32' option for x86 code production)
If those "Intellistore" machines are x86_64 ones and they aren't
provided only with "brain damaged" GCCs
which can only produce 64-bit code, then just using '-m32' in the
compile options would cause code for the
x86 mode being produced ! Quoting the gcc-3.3.6 manual :
http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
----------------- clip ------------------------------------
These `-m' switches are supported in addition to the above on AMD x86-64
processors in 64-bit environments.
|-m32|
|-m64|
Generate code for a 32-bit or 64-bit environment. The 32-bit
environment sets int, long and pointer to 32 bits and generates code
that runs on any i386 system. The 64-bit environment sets int to 32
bits and long and pointer to 64 bits and generates code for AMD's
x86-64 architecture.
----------------- clip ------------------------------------
My thought is that one cannot mix 64-bit and 32-bit pieces in x86_64
just like with 'arm' (32-bit) and 'thumb' (16-bit)
in ARM. So the produced code must be either purely x86_64 or x86 code
for each module for the executable....
