CPUDETECT.S, error building rtlib on windows

Windows specific questions.
marcov
Posts: 2298
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: CPUDETECT.S, error building rtlib on windows

Postby marcov » Sep 11, 2014 13:58

TJF wrote: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
Posts: 3324
Joined: Dec 06, 2009 22:27
Location: N47°, E15°

Re: CPUDETECT.S, error building rtlib on windows

Postby TJF » Sep 11, 2014 15:16

marcov wrote:[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
Posts: 2298
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: CPUDETECT.S, error building rtlib on windows

Postby marcov » Sep 11, 2014 21:25

TJF wrote:
marcov wrote:[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
Posts: 165
Joined: Oct 16, 2009 14:44
Location: Jodhpur, Rajputana, Empire of Aryavart
Contact:

Re: CPUDETECT.S, error building rtlib on windows

Postby leodescal » Sep 14, 2014 7:13

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
Posts: 3324
Joined: Dec 06, 2009 22:27
Location: N47°, E15°

Re: CPUDETECT.S, error building rtlib on windows

Postby TJF » Sep 14, 2014 8:54

leodescal wrote: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
Posts: 2298
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: CPUDETECT.S, error building rtlib on windows

Postby marcov » Sep 14, 2014 10:47

leodescal wrote: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
Site Admin
Posts: 5716
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: CPUDETECT.S, error building rtlib on windows

Postby counting_pine » Mar 17, 2017 17:05

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
Site Admin
Posts: 3132
Joined: Jul 28, 2005 14:45
Location: Germany

Re: CPUDETECT.S, error building rtlib on windows

Postby dkl » Mar 17, 2017 18:05

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.

Return to “Windows”

Who is online

Users browsing this forum: No registered users and 1 guest