Pure FB Runtime Library (in progress)

User projects written in or related to FreeBASIC.
St_W
Posts: 1352
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: Pure FB Runtime Library (in progress)

Postby St_W » Jan 17, 2018 20:51

I'm not completely sure, but doesn't fbc handle ASC calls with constant values during compile time instead of calling the ASC function at runtime?
SARG
Posts: 857
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Pure FB Runtime Library (in progress)

Postby SARG » Jan 17, 2018 21:03

St_W wrote:I'm not completely sure, but doesn't fbc handle ASC calls with constant values during compile time instead of calling the ASC function at runtime?
You're right.
With gas (not tested with gcc)

Code: Select all

Print Asc("T") ''value 84

Code: Select all

##Print Asc("T")
   push 1
   push 84
   push 0
   call _fb_PrintUInt@12
Imortis
Posts: 1568
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: Pure FB Runtime Library (in progress)

Postby Imortis » Jan 17, 2018 21:50

If rtl-string,bi is to be believed, no. It looks like it maps the ASC to the RTlib function, just like everything else.
TeeEmCee
Posts: 243
Joined: Jul 22, 2006 0:54
Location: Auckland

Re: Pure FB Runtime Library (in progress)

Postby TeeEmCee » Jan 18, 2018 10:48

If ASC is called with a string literal then it can be evaluated at compile-time. Otherwise the call to the runtime has to be preserved. See cStrASC in parser-quirk-string.bas
The same thing applies to other string and wstring functions including string concatenation (I'm not sure if all are optimised out, but all the ones I checked are). However, if you are crosscompiling to a platform with a different wchar_t size, then operations on wstrings are not performed at compile-time, because FB supports only UCS-2, not UTF-16, and therefore when fbc is running on Windows it's incapable of correctly performing operations on wstrings containing high code points and getting the same result as under Unix. You can call that either a bug or an unimplemented feature.

Of course, there's no excuse either for not using character literals like '\n' instead of ASCII codes in the original C source.
counting_pine
Site Admin
Posts: 5946
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Pure FB Runtime Library (in progress)

Postby counting_pine » Jan 18, 2018 13:35

ASC() produces compile-time constants when it can. You can verify it with code like:

Code: Select all

const char_A = asc("A")
#assert char_A = 65
Imortis
Posts: 1568
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: Pure FB Runtime Library (in progress)

Postby Imortis » Jan 18, 2018 20:25

By the way, the problem with file_datetime.bas (and I assume file_attr.bas) is because of some duplicate defs:
win32\wchar.bi
win32\stat.bi
io.bi

I edited my copies of these with #ifndefs to make the errors go away since the definitions are exactly the same.
St_W
Posts: 1352
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: Pure FB Runtime Library (in progress)

Postby St_W » Jan 19, 2018 17:07

IIRC you can redefine types/symbols in C as long as you use the same definition and the compiler won't complain.
Imortis
Posts: 1568
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: Pure FB Runtime Library (in progress)

Postby Imortis » Jan 19, 2018 22:05

I may have asked about this already, but the rtlib in fbrt0.c has these lines:

Code: Select all

static void * priorityhDoInit __attribute__((section(".ctors.65435"), used)) = fb_hDoInit;
static void * priorityhDoExit __attribute__((section(".dtors.65435"), used)) = fb_hDoExit;


What do I do with these?
TeeEmCee
Posts: 243
Joined: Jul 22, 2006 0:54
Location: Auckland

Re: Pure FB Runtime Library (in progress)

Postby TeeEmCee » Jan 20, 2018 0:48

You did ask before. See viewtopic.php?p=237909#p237909 and following replies.

To summarise, make these module constructor and destructors:
TeeEmCee wrote:Maybe we should just use ctor/dtor priority 101 for the FB runtime, and disallow users from using priority 101. Then we can avoid nonportable __attribute__((section)) hacks which in general can't be done on every OS.
Constructors/destructors are already implemented in FB; see here.


You won't need the ifdefs for Darwin, etc. Just remove them all, so all platforms use the same code. fbc is responsible for handling OS differences.
Imortis
Posts: 1568
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: Pure FB Runtime Library (in progress)

Postby Imortis » Jan 20, 2018 1:07

TeeEmCee wrote:You did ask before. See viewtopic.php?p=237909#p237909 and following replies.

To summarise, make these module constructor and destructors:
TeeEmCee wrote:Maybe we should just use ctor/dtor priority 101 for the FB runtime, and disallow users from using priority 101. Then we can avoid nonportable __attribute__((section)) hacks which in general can't be done on every OS.
Constructors/destructors are already implemented in FB; see here.


You won't need the ifdefs for Darwin, etc. Just remove them all, so all platforms use the same code. fbc is responsible for handling OS differences.


Wow... I missed that WHOLE SECTION of this thread... I am so sorry.
coderJeff
Site Admin
Posts: 2685
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Pure FB Runtime Library (in progress)

Postby coderJeff » Jan 21, 2018 15:43

The chicken or egg problem shows up when:
1) the compiler needs to use a function in it's own source code that does not yet exist (in compiler and/or run-time)
2) the compiler uses a run-time function that changes by name, number of arguments, type of arguments, or occasionally has different behaviour
Choices for solving this problem could be using, a less than optimal or alternate version of the function defined within the compiler only, or having 2 sequential releases of the compiler/run-time, the first makes the function available, the second actually uses it.

With fb's ASC() aka fb_ASC() in the runtime, chicken/egg is not the issue, as ASC() is well known function and you are using same name fb_ASC(), in the linker's namespace.

The differences to note is that ASC() aka fb_ASC() is used from 2 different places:
1) The compiler uses fb_ASC() runtime function itself to evalulate constants at compile time of user code
2) The user's code uses fb_ASC() at run-time to evaulate user code at run-time

Suppose we start with a working compiler, but have a bad implementation of fb_ASC()
1) Compilation of fbrt will appear to work OK, compile time constants in fbrt will be handled fine.
2) If using same working compiler and newly compiled fbrt, test-suite compile time tests should pass, run-time tests should fail
3) After re-linking fbrt with fbc compiler, in test-suite, both compile time tests and run-time tests will fail.

Suppose fb_ASC() implentation is good, following:
4) After re-building fbc and rtlib, should expect binary differences in the fbc executable
5) After re-building fbc and rtlib, yet again, should expect binary stability in the final fbc executable

If it's possible, and looks like it is with TeeEmCee's makefile, to test as you go, and to run the test-suite on a second generation build of the compiler. When tests are all passing, then rebuild fbc three and four times to check for binary stability.
St_W
Posts: 1352
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: Pure FB Runtime Library (in progress)

Postby St_W » Jan 21, 2018 17:20

Building the compiler twice before testing has been necessary and is done also for fbc with non-FB runtime library (e.g. think of the introduction of the boolean datatype a few years ago). The new thing is just that - in addition to fbc - also the runtime library itself will need to be recompiled, which wasn't necessary previously. That is a downside of having a runtime library written in FB (among others).
coderJeff
Site Admin
Posts: 2685
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Pure FB Runtime Library (in progress)

Postby coderJeff » Jan 21, 2018 18:03

St_W wrote:That is a downside of having a runtime library written in FB (among others).

yeah, on one hand, I think rtlib implemented in fb makes compiler package complete, and might encourage non-C users to understand rtlib. On the other hand, on any system other than x86 w/gas, code is converted back to C and passed on to gcc. And in fbbindgen thread, automatically read .h, to convert to .bi, to convert back C. Not trying to discourage anyone, but I think does force one to evaluate the project's goals.
marcov
Posts: 2589
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: Pure FB Runtime Library (in progress)

Postby marcov » Jan 21, 2018 19:56

(This is fairly normal, in a standard build, FPC compiles itself 3 times, and the RTL/RTS 4 times.

Roughly the same 2 times+ 1 extra pass to compare with (so to make sure that the binaries of the second and third pass are the same, compiler stability reqirement), then recompile the RTL again for distribution, with all optimizations and section smartlinking on.
)
Imortis
Posts: 1568
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: Pure FB Runtime Library (in progress)

Postby Imortis » Jan 24, 2018 18:17

Code: Select all

for( ;; )


That is in some code in the RTlib. It looks like there is a specific condition where the loop is broken, but it does not seem to count anything. Can I just replace it with a do...loop? Or is there something else I am missing?

Return to “Projects”

Who is online

Users browsing this forum: No registered users and 3 guests