[fpc-devel]Some crazy ideas

[Peter Vreman]

At 12:38 6-2-02, you wrote:
>Hello all,
>
>Athough I don't introduce new features to FPC now (I hope, only
>temporarily: while I have some important work which is not
>FPC-related) an only sent two incompatibities reports (sorry, after
>changing of my E-Mail client I forgot to translate my name in it from
>cyrillic to latin ABC immediately) but in between times I accumulated
>some crazy ideas which, I hope, could be interestnig.
>
>Idea (1): Possible full Unicode support.
>Now in FPC exists objpas module which does redeclare some types and
>functions fir $objfpc and $delphi modes. But similarly a UniFpc module
>could be introduced which must:
>1) redeclare char, pchar, string to wide;
>2) owerwrite some RTL functions (write, str, val etc) to support
>Unicode by default;
>I see some problems here, to be frankly:

There are widestr (UTF16) versions available in the 1.1 RTL. Only the 
conversion routines between widestr-ansistr are not implemented, the 
default is to only allow 7bit characters. There need to be some conversion 
routines for different charsets.

For the rest the widechar and widestr should be working

>1) UniFpc should be separate for every target because it must use
>OS-depended API;
>2) Because FPC must be also cross-compiler, converting ANSI to unicode
>cannot use direct calling of OS API conversation functions because
>Unicode is different in different operating systems; compiler should use
>internal tables to recoding;
>2) at least one additional complier directive should be used:
>{$charset unicode,nnnn|$charset ansi}

I think will be more complex than it looks. The compiler is build around 
shortstring for speed. Constant widestrings and long ansistrings are 
supported using helpers.

The solution is to implement the unicode handling only in the scanner part. 
The routines for reading char/identifier/comments from a filebuffer should 
all support the unicode (utf-8,utf-16?). This can be added by overriding 
these routines in a new class. But be carefull because most routines are 
called a lot and are therefor speed critical. For parsing constant 
string/char check for 7bit values. If all chars in the string then return a 
normale ascii string and all other are widestrings.

You don't need to know all compiler internals to implement this part. Only 
understanding how the scanner part works is enough.


>Idea (2): possible way to support public inline procedures/functions
>and some possible consequences
>
>Here I would explain full way of my reflections.
>If we will use inline procedure which is written in one unit, in other
>units, we cannot save it as compiled machine code (because otherwise
>then we need to disassemble it before use). Then I
>make a conclusion: code of inline procedure must be stored into ppu
>file. But as what? At first look, storing it as a sequence of assember
>instructions seems to be a good idea. But really this way could cause
>some problems, mainly in optimization quality. For optimizer that
>could be not indifferent, is a parameter got by inline function a
>constant, a memory-stored or a register-stored variable. Therefore,
>maybe, that would be better, to save inline procedure in ppu-file as a
>sequence of TOKENS (may be, partially optimized).

This is still a TODO. We are gonna store the tnode tree in the ppu file. 
The use of tokens is not possible as the inlining takes place in the 
codegenerator part and not at the scanner level (there it will be macro's).


>But then for us some new possibities will be available, if we will
>store some parts of code not fully compiled (for releasing at
>including into "pseudo-caller" stage). Then become to be not meanless
>declarations like
>
>procedure TheProc(type UserType, var x:inline; y:inline);inline;
>  begin
>   x:=x+UserType(y);
>  end;
>.....
>TheProc(integer, AnIntegerVariable,'A');
>TheProc(shortstring,AStringVariable,'B');
>
>Furthermore, this way could help to make in FreePascal full support of
>class templates, like C++!

I never used it myself, but looking at the above example i don't like it. 
You can better use variants or use overloaded routines.


Peter