Pure FB Runtime Library (in progress)

[dodicat]

Is your aim to create a freebasic runtime library without C involved?
If it is then do you intend to use -gen gas as the default compiler, and have -gen gcc an option (as it is at the moment)

[Imortis]

The only difference will be in how FBC is compiled. It will require less GCC to compile. It will still be required for the fbgfx, but the rtlib will be compiled in FB itself.

OTHER NOTE:

Code: Select all

return memcpy(wcstr,mbstr,count), count;

What the hell is that?! C does not allow multiple return values does it?

[angros47]

Does this help? https://stackoverflow.com/questions/320 ... c-function

[Imortis]

Ah! Yes. Thanks.

[TeeEmCee]

What are the cross-backend asm options?

I'm not sure what you mean by this, but I guess you're asking about using inline asm in FB in a way that's portable between gcc and gas backends.

fbc has "-asm att" and "-asm intel" options to select asm syntax.
att syntax only works when using -gen gcc, because the gas backend is intel syntax. -asm att actually signifcantly changes the syntax of FB asm blocks to be like GCC asm syntax.
intel syntax is fairly portable between backends (I've hardly touched it, don't really know how much), and doesn't use or support GCC syntax. In this mode, there's an extra layer of translation between what's in the .bas file and what the emitter actually outputs. The gas emitter is completely predictable because it doesn't do register allocation or much in the way of optimisation, while gcc isn't. So assumptions made are a possible source of breakage. Also, support for intel syntax in the OS assembler is usually terrible/completely broken except on GNU systems.

[marcov]

What are the cross-backend asm options?

I'm not sure what you mean by this, but I guess you're asking about using inline asm in FB in a way that's portable between gcc and gas backends.

Yes, depends. I'm asking for the cases that are generally dependent of having non ( or very old/out of date) library options. Dos, OS/2 etc, since that is what such fallbacks typically are for.

Note that inline asm is an ambiguous term. It can refer to assembler to be inlined (LLVM node assembler, or that hackish GCC syntax), assembler inside a FB block/function, or a wholly asm function inlined in a FB source file, with or without compiler generated prologue and epilogue.

Since most asm will be fallback code, any of these that is cross-backend portable.

fbc has "-asm att" and "-asm intel" options to select asm syntax.
att syntax only works when using -gen gcc, because the gas backend is intel syntax. -asm att actually signifcantly changes the syntax of FB asm blocks to be like GCC asm syntax.

Well, such translation is a good things since it abstracts the frontend syntax from the backend syntax.

[TeeEmCee]

I don't know what you mean by "non-library options". You mean platforms without a working libc or other requirements?

The gcc backend doesn't support naked functions (without prologue/epilogue), but it could be supported, it just isn't (fully) implemented. (You get strange errors if you try it which seem to indicate it's part-implemented)

You can't inline assembly outside of a function in FB, because all statements outside a function are actually inside an outer global-scope function. If it's the main module that outer function is main(), otherwise its the module's constructor.

[marcov]

I don't know what you mean by "non-library options". You mean platforms without a working libc or other requirements?

Yes, or very old, or one that you simply don't want to use. I asked because that is what these fallbacks are for, and you really want to avoid the HLL case, specially if you update the asm ones marginally. (with e.g. code based on various asm forums and documentation like Agner Fog's)

One could argue though that such fallback options wouldn't be using gcc backend to begin with.

The gcc backend doesn't support naked functions (without prologue/epilogue), but it could be supported, it just isn't (fully) implemented. (You get strange errors if you try it which seem to indicate it's part-implemented)

If you generate code for small fixed-sized moves directly, the naked optimization is not so important I guess.

You can't inline assembly outside of a function in FB, because all statements outside a function are actually inside an outer global-scope function. If it's the main module that outer function is main(), otherwise its the module's constructor.

That I understand, with outside of a (FB) function I meant outside a BASIC function, iow just function declaration and asm (naked or not)

[TeeEmCee]

The fallbacks you're talking about... the asm versions of those functions which Imortis posted aren't intended as fallbacks. They're attempted optimisations. Those are all trivial functions, making them practical to rewrite, but FB's rtlib calls plenty of other far more significant libc functions. Rewriting libc as well as libfb in FB, while a fun project, sounds like scope creep! But it's a separate project.

I know where you're coming from. I have had the experience of dealing with a broken libc: on older versions of android, the libc (Bionic) is utter crap. In particular it doesn't have any wchar support, I worked around it by redefining wchar (wstring in FB) as char.
But these days android's libc is vastly better (but still literally sub-standard).

you really want to avoid the HLL case, specially if you update the asm ones marginally. (with e.g. code based on various asm forums and documentation like Agner Fog's)

HLL = High level assembler? Sorry, I don't follow what you're talking about.

That I understand, with outside of a (FB) function I meant outside a BASIC function, iow just function declaration and asm (naked or not)

I guess you could put one function declaration in the middle of another (inside the module ctor), if you precede it with a 'ret', but that's a total hack. Or proper support could be implemented in the compiler. But why would you want to, instead of just using a seperate assembly file?

[marcov]

The fallbacks you're talking about... the asm versions of those functions which Imortis posted aren't intended as fallbacks. They're attempted optimisations.

But those functions are in libc? As optimizations they are poor. The FB cases can also be improved.

Those are all trivial functions, making them practical to rewrite, but FB's rtlib calls plenty of other far more significant libc functions. Rewriting libc as well as libfb in FB, while a fun project, sounds like scope creep! But it's a separate project.

I assumed these functions would be used from libc if the target had a decent one, so all functions there (be it Basic or asm) are for cases where that is not available or decrepit. I was thinking mostly about older non *nix targets like dos and OS/2 (and Amiga in our case, thought that is typically not x86).

And getting rid of libc is a different subject.

you really want to avoid the HLL case, specially if you update the asm ones marginally. (with e.g. code based on various asm forums and documentation like Agner Fog's)

HLL = High level assembler? Sorry, I don't follow what you're talking about.

High Level Language, the primitives in FB in this case.

I guess you could put one function declaration in the middle of another (inside the module ctor), if you precede it with a 'ret', but that's a total hack. Or proper support could be implemented in the compiler. But why would you want to, instead of just using a seperate assembly file?

Then you are at the mercy of the backend assembler again, and don't have symbol support. I've the feeling we are talking at crossroads. I just wanted a normal function, wholly defined in assembler. If possible with prologue and epilogue, if not, then with as minimal as possible.

That said, avoid the current move functions in FPC are pascal wrappers that select the assembler routine (forward/backward, small move or big move?). The big moves are stored in procedurevariables (function pointers) that are set on startup after CPU detection.

See e.g.
https://svn.freepascal.org/cgi-bin/view ... iew=markup

An older asm move is in https://svn.freepascal.org/cgi-bin/view ... iew=markup

I assume libc would do something similar.

[Imortis]

Okay new question:

Code: Select all

static FB_STR_TMPDESC fb_tmpdsTB[FB_STR_TMPDESCRIPTORS];

Is later used like this:

Code: Select all

item < fb_tmpdsTB+0

I assumed the first was just an array declare, roughly this in FB:

Code: Select all

dim fb_tmpdsTB(FB_STR_TMPDESCRIPTORS) as FB_STR_TMPDESC

I am guessing that C arrays are just contiguous blocks of memory. That being said, how do I write the same thing in FB? Like this?

Code: Select all

item < @fb_tmpdsTB+0

[St_W]

You can write it like this:

Code: Select all

item < @fb_tmpdsTB(0)

The C expression "array+n" corresponds to "@array(n)" in FreeBasic. Using array without specifying an index is not possible in FB as far as I know - fxm can tell you for sure, in case it actually is :-)

[fxm]

- Yes, there is no specific keyword to get the start address of an array like the one (StrPtr) to find the start address of a character string.
- We only can get the address of any array element (n), identified by its index: @array(n)
- So to get the start address of an array, the general syntax could be: @array(LBound(array))
- If the low bound is not specifies when defining or redefining the array, this one is fixed to 0 per default, so that the previous syntax can be shortened to: @array(0)

[MrSwiss]

Sorry fxm,

> there is no specific keyword ...

don't agree on that one, there is: VarPtr used as follows, on a array:

Code: Select all

VarPtr(array(0))  ' or
VarPtr(LBound(array))

[fxm]

"@" is a shortcut for "VarPtr" when applied on variable or object, and "array(0)" is not an array but just a particular element of the array.
A syntax as "VarPtr(array)" or "VarPtr(array())" is disallowed.