CPUDETECT.S, error building rtlib on windows

[marcov]

When using the C backend (-gen gcc), there's no need for macro translation.

I don't know. What if you use a C macro in an FB expression? How will you do any semantic checking at all?

[TJF]

[What if you use a C macro in an FB expression? How will you do any semantic checking at all?

No semantic check for C macros by fbc. This gets done by the C compiler. This means all variable, function or macro names must get passed unchanged to the C source (case-sensitive).

[marcov]

[What if you use a C macro in an FB expression? How will you do any semantic checking at all?

No semantic check for C macros by fbc.
This gets done by the C compiler. This means all variable, function or macro names must get passed unchanged to the C source (case-sensitive).

Generating code for the FB expressions might depend on that semantic information.

[leodescal]

There would really be no need of translating the C code into FBC, just this is needed to be done:
1. Understading C build-in/factory types.
2. Recognizing declared functions, variables, etc.
3. Then just use the C header directly using C compiler.

Theortically, this is a simple solution to use the C headers directly and thus solving the need of doing mammoth task of staying updated to every possible library on earth. The number of libraries would just increase, old libraries would be updated. The manpower required to stay updated isn't with us, as time would pass we'll get more and more behind.

But still this method might have one probable error, double defination between the FreeBASIC and C compiler. To make sure this error don't occur FreeBASIC shouldn't emit the definations it took from C headers into emitted .c file. Let C compiler take them from C header files directly.

[TJF]

But still this method might have one probable error, double defination between the FreeBASIC and C compiler. To make sure this error don't occur FreeBASIC shouldn't emit the definations it took from C headers into emitted .c file. Let C compiler take them from C header files directly.

To avoid double definitions, the FB compiler has to scan the C headers. In case of macros it only needs the name and the number of parameters. The macro body gets passed as-is to the C code.

I'm sure that can get realized. The Vala compiler works that way. (Vala also supports a Basic-like syntax.)

[marcov]

There would really be no need of translating the C code into FBC, just this is needed to be done:
1. Understading C build-in/factory types.
2. Recognizing declared functions, variables, etc.
3. Then just use the C header directly using C compiler.

So where comes the use of C in FB here? Here you say only C code can use the headers. But we want to use the headers from FB?

Moreover it is not translating the C to FB, it is generating semantic information for it in the compiler. IOW understanding. A counter example that I can quickly think of:

Code: Select all

     res=fb_func(c_macro(fb_var));   
  

with fb_func overloaded.

Anything where typing is not 100% rigid (overloading, typeconversions) will be dangerous. Even simple numerics can, does a macro return an integer or a float? Also I can imagine problems in mixed expressions with macros due to namemangling. (e.g. for the benefit of namespaces). I can't really put the finger on it with a smoking gun example though.

The only solution I see is to refuse ambiguous constructs as above (compiler errors with "can't determine type of <expr> to select overload"), and requiring people to assign expressions from the C world to a typed variable first, or have the user insert forced casts. But then backend decisions bleed into the frontend.

But I'm from a mindset where users should never see backend errors, and that every backend error (that is not a matter of installation) is a compiler bug. If your users are supposed to be experienced C users, that might be different.

Theortically, this is a simple solution to use the C headers directly and thus solving the need of doing mammoth task of staying updated to every possible library on earth.

I don't see a solution, merely a hope. And IMHO a false one. Or at least the way it is presented here, as easy. I can be wrong, the C backend also seems to deliver less problems than I thought.

To me, such schemes only if your compiler is a pure translator that mostly does some substitutions and then tosses it over to C, and your languages map 1:1. FB doesn't, has its own typesystem, semantics, OO extensions etc.

The number of libraries would just increase, old libraries would be updated. The manpower required to stay updated isn't with us, as time would pass we'll get more and more behind.

That is true, but that it hurts doesn't make the alternative possible. I think if you go that way you will get mired in constant grey areas, users demanding to understand more of C so that their header will pass etc. It won't be simply implement and be done. It will be a forever burden and catch-up too.

And that all falls on the compiler guy, since remember that a fact is that more people can do header work than compiler work

[counting_pine]

Note to self: if in future you see the "operator type mismatch" assembler errors while trying to set up a new Win64 build environment, it might be that you forgot to create a config.mk file containing 'TARGET_ARCH = x86_64'.

[dkl]

Yea, the problem usually is that the uname command from MSYS returns 32bit even if you have a 64bit gcc, so the FB makefile thinks it's building for 32bit, and chooses sources files, pre-#defines and directory layout accordingly, but uses the 64bit gcc when compiling stuff.

I think that problem is solved in the MSYS2 project. And of course we could adjust the FB makefile to always pass -m32 or -m64 to gcc, and -arch 32/64 to fbc, so that at least it can be sure that it's compiling for the target that it expects to be compiling for.