CPUDETECT.S, error building rtlib on windows

[leodescal]

Hello, I am trying to build 32 bit windows version from sources (git). I am following this guide- http://www.freebasic.net/wiki/wikka.php ... ildWindows
Everything was going fine until this error:

Code: Select all

CC src/rtlib/obj/win32/utf_convto_wchar.o
CC src/rtlib/obj/win32/utf_core.o
CC src/rtlib/obj/win32/vfs_open.o
CPPAS src/rtlib/obj/win32/alloca.o
CPPAS src/rtlib/obj/win32/cpudetect.o
CC src/rtlib/obj/win32/mt/array_boundchk.o
src/rtlib/x86/cpudetectCC src/rtlib/obj/win32/mt/array_clear.o.s
Assembler messages:
src/rtlib/x86/cpudetect.s:29: Error: operand type mismatch for `push'
src/rtlib/x86/cpudetect.s:31: Error: operand type mismatch for `push'
src/rtlib/x86/cpudetect.s:32: Error: operand type mismatch for `push'
src/rtlib/x86/cpudetect.s:33: Error: operand type mismatch for `push'
src/rtlib/x86/cpudetect.s:36: Error: invalid instruction suffix for `pushf'
src/rtlib/x86/cpudetect.s:37: Error: operand type mismatch for `pop'
src/rtlib/x86/cpudetect.s:40: Error: operand type mismatch for `push'
src/rtlib/x86/cpudetect.s:41: Error: invalid instruction suffix for `popf'
src/rtlib/x86/cpudetect.s:42: Error: invalid instruction suffix for `pushf'
src/rtlib/x86/cpudetect.s:43: Error: operand type mismatch for `pop'
src/rtlib/x86/cpudetect.s:51: Error: invalid instruction suffix for `pushf'
src/rtlib/x86/cpudetect.s:52: Error: operand type mismatch for `pop'
src/rtlib/x86/cpudetect.s:55: Error: operand type mismatch for `push'
src/rtlib/x86/cpudetect.s:56: Error: invalid instruction suffix for `popf'
src/rtlib/x86/cpudetect.s:57: Error: invalid instruction suffix for `pushf'
src/rtlib/x86/cpudetect.s:58: Error: operand type mismatch foCC src/rtlib/obj/wi
n32/mt/array_clearobj.or
op'
src/rtlib/x86/cpudetect.s:66: Error: operand type mismatch for `push'
src/rtlib/x86/cpudetect.s:82: Error: operand type mismatch for `pop'
src/rtlib/x86/cpudetect.s:83: Error: operand type mismatch for `pop'
src/rtlib/x86/cpudetect.s:84: Error: operand type mismatch for `pop'
src/rtlib/x86/cpudetect.s:85: Error: operand type mismatch for `pop'
make: *** [src/rtlib/obj/win32/cpudetect.o] Error 1
make: *** Waiting for unfinished jobs....

Warguy@meinpc /c/Users/Warguy/Desktop/fbc-master
$

GCC version:

Code: Select all

Warguy@meinpc /c/Users/Warguy/Desktop/fbc-master
$ gcc --version
gcc.exe (tdm64-2) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[dkl]

Your gcc --version output includes tdm64, is it really TDM-GCC 64bit? In that case you need to add extra options to (cross)compile to 32bit: CC='gcc -m32'. Or use a gcc that defaults to compiling for 32bit.

[leodescal]

Your gcc --version output includes tdm64, is it really TDM-GCC 64bit? In that case you need to add extra options to (cross)compile to 32bit: CC='gcc -m32'. Or use a gcc that defaults to compiling for 32bit.

Yes it is a 64 bit GCC/TDM compiler. I added -m32 to the gcc flag, and it worked. Then I was able to compile FreeBASIC for 64 bit. I had initial problem with libraries but later copying the 64 bit libraries from GCC-TDM helped. And the result is:


I have tried it on some smaller programs which don't need external 3rd party libraries, it seem to work all right for now. Are there any known potential bugs and limitations to keep in mind?

[dkl]

The main issue remaining is that most headers from the inc/ (or include/freebasic/) directory are not updated for 64bit support yet. I only adjusted the CRT and CUnit headers when making the 64bit changes initially. Unfortunately the Win32 API headers do not support 64bit yet, and they're also the most complex to update.

Besides that you should keep in mind that 64bit support is based on -gen gcc, so you need gcc, and the known -gen gcc limitations apply (no va_* vararg function support, different inline assembly).

[leodescal]

The main issue remaining is that most headers from the inc/ (or include/freebasic/) directory are not updated for 64bit support yet. I only adjusted the CRT and CUnit headers when making the 64bit changes initially. Unfortunately the Win32 API headers do not support 64bit yet, and they're also the most complex to update.

Besides that you should keep in mind that 64bit support is based on -gen gcc, so you need gcc, and the known -gen gcc limitations apply (no va_* vararg function support, different inline assembly).

I tried to compile few win32 api examples from GUI folder. None of them worked. How long can we really go behind having native includes, it is definitely a race against time. These APIs would get updated faster than our manpower to cover them. Wouldn't in long term reading the C headers directly be a better solution?
On short term basis I am trying to test if I can go away with defining just the data types and functions I need from a particular library.

EDIT:
wx-c would be a nice to have on 64 bit, my attempts to compile it on 64 bit Linux failed. I'll now try to compile it on 64 bit windows. If failed, I think it would be nice idea to slowly and steadily create a clear 'bit neutral' version of it.

[marcov]

These APIs would get updated faster than our manpower to cover them. Wouldn't in long term reading the C headers directly be a better solution?

If the compiler could read and interpret them, so could a simple conversion program. (probably better, since it has less baggage, and can be fed with exceptions and disambiguating information).

So the fact that such fully automatic utility doesn't exist means the compiler probably couldn't either, unless the compiler is effectively an extension to a C language compiler (I mean here also frontend not the C backend of FB)

The trouble with one header translation is that the header is an translation of what is actually meant to the C parsing model.

Automatically translating C often means converting the two step (preprocess - declare) C parsing model back to what is originally meant, which is hard to do automatically.

[TJF]

So the fact that such fully automatic utility doesn't exist means the compiler probably couldn't either.

Fully automatic translation is possible with .gir / .typelib files (G-Object Introspection, see project GirToBac).

[marcov]

So the fact that such fully automatic utility doesn't exist means the compiler probably couldn't either.

Fully automatic translation is possible with .gir / .typelib files (G-Object Introspection, see project GirToBac).

Just get Microsoft to use them then. (we were not talking about your walled garden of gnomes)

[TJF]

My garden is fine. No walls, no fences, no windows, no gates ...

[dkl]

Having fbc read .h files directly would be great, if only it would be that easy...

Interestingly enough, having the translation tool built-in into fbc means it can be simpler than an external tool, because it only has to worry about one compilation target at a time (instead of having to generate a .bi which supports multiple targets). .bi files wouldn't even go away - they'd still be needed to include the proper .h files, provide hints for the translation, and to provide declarations that cannot be translated automatically.

Of course there are a lot of technical issues, but I think all of them can be solved. Overall though it makes more a massive change. If it's fast enough though I could see it work nicely. I'd like to give it a try sometime... I already have the custom C preprocessor + parser in fbfrog anyways.

[marcov]

How do you translate

Code: Select all

#define something(x)  {any C code using as yet undefined variables etc}

E.g. stuff like (from FreeBSD headers)

Code: Select all

#define FD_ISSET(n, p)  (((p)->__fds_bits[(n)/_NFDBITS] & __fdset_mask(n)) != 0
#define FD_SET(n, p)    ((p)->__fds_bits[(n)/_NFDBITS] |= __fdset_mask(n))

Type of p, n is unknown. n might be infered from __fds_bits and _mask types.

[D.J.Peters]

why not including #include "crt/sys/select.bi" ?
This is the FreeBASIC version of your posted socketset macros.

Joshy

Code: Select all

#define FD_SET(n, p)     (p)->__fds_bits[(n)/_NFDBITS] or= __fdset_mask(n)
#define FD_ISSET(n, p)  (((p)->__fds_bits[(n)/_NFDBITS] and __fdset_mask(n)) <> 0)

[marcov]

Yes, but keep in mind that it can be _any_ C _code_ not just declarations. (e.g. b+tree implementations). And you need to replicate the exact C compiler environment for any used compiler on any target. (so built in predefined values, modifiers, attributes etc, or it will die on the first sizeof(a type with an attribute).

Another fun one from FreeBSD. sysctl this time.

Code: Select all

#define SYSCTL_OID(parent, nbr, name, kind, a1, a2, handler, fmt, descr) \
        static struct sysctl_oid sysctl__##parent##_##name = {           \
                &sysctl_##parent##_children, { 0 },                      \
                nbr, kind, a1, a2, #name, handler, fmt, 0, 0, __DESCR(descr) };
        DATA_SET(sysctl_set, sysctl__##parent##_##name)

(btw these are all cases why I gave up header converters that try to emulate compiler in an automated way. Of course in our case it is worse, since FPC has NO parameterized macros, no ternary operator etc etc)

In general, even if you don't see it my way, believe me, the FreeBSD sysctl.h header will make a good test :-)

[dkl]

Yea, certain #defines (same goes for inline functions unless they're simple enough) will always have to be stripped/ignored in the automatic translation, and must be translated manually. Hence why .bi's will always be needed even if fbc had the automatic translation built-in.

[TJF]

When using the C backend (-gen gcc), there's no need for macro translation. The C header gets passed to the C compiler and fbc just picks the macro names and number of parameters. Also for CONST, TYPE, ENUM, FUNCTION. SUB, ... just the names and types need to get fetched from the C headers to translate the FB code.

This can be done full-autmatic. But in that case the naming in FreeBASIC must be case-sensitive (and no more -gen gas).