Pure FB Runtime Library (in progress)

[St_W]

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]

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]

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]

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]

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]

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]

IIRC you can redefine types/symbols in C as long as you use the same definition and the compiler won't complain.

[Imortis]

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]

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

To summarise, make these module constructor and destructors:

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]

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

To summarise, make these module constructor and destructors:

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]

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]

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]

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]

(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]

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?