Language constructs and types that dependent upon system unit

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Language constructs and types that dependent upon system unit

gabor-10
Hello!
I would like to write some code that will be static linked with C
application. In addition, I would like to avoid linking system and rtl
units and would use only routines that come with C app and library (I
heard that combining fpc rtl with C application is not a good idea and
there are problems with initialization/finalization sections).
I know that some of language constructs and types require additional
code (such as memory management, etc.), which I would avoid.
I know that following types require extra code:
object, class, sting, dynamic array, try..except.
What else should I avoid?

Regards,
Michał.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Language constructs and types that dependent upon system unit

Jonas Maebe-3
On 19/01/17 20:15, gabor wrote:

> I would like to write some code that will be static linked with C
> application. In addition, I would like to avoid linking system and rtl
> units and would use only routines that come with C app and library (I
> heard that combining fpc rtl with C application is not a good idea and
> there are problems with initialization/finalization sections).
> I know that some of language constructs and types require additional
> code (such as memory management, etc.), which I would avoid.
> I know that following types require extra code:
> object, class, sting, dynamic array, try..except.
> What else should I avoid?

The system unit implements parts of the language that are too complex to
generate directly in the compiler. Which parts these are depend, a.o.,
on the target architecture and the target operating system.

It is therefore not possible to give an answer to your question that is
generally valid. Furthermore, the answer could become wrong at any time
because all of that is implementation-dependent.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Language constructs and types that dependent upon system unit

gabor-10
I was hoping that maybe there is an easy answer. But I understand.
Thanks.

Michał.

W dniu 2017-01-19 o 20:28, Jonas Maebe pisze:
> It is therefore not possible to give an answer to your question that is
> generally valid. Furthermore, the answer could become wrong at any time
> because all of that is implementation-dependent.
>
>
> Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Language constructs and types that dependent upon system unit

Felipe Monteiro de Carvalho
In reply to this post by gabor-10
On Thu, Jan 19, 2017 at 8:15 PM, gabor <[hidden email]> wrote:
> problems with initialization/finalization sections).
...
> I know that following types require extra code:
> object, class, sting, dynamic array, try..except.
> What else should I avoid?

I think it is a huge exaggeration to rule out all of that. I think
that most of this stuff from basic language or system unit should work
just fine. Indeed some might not work, but most should work.

If you use the unit cmem (or even better if you make your own memory
manager that redirects to the C side), I don't see why
object/class/string/dynamic arrays should fail, when used internally
in the Pascal side.

try...except will probably indeed not work, because C often uses a
different exception mask than FPC or something like that.

I didn't try it myself recently, but instead of going bare-bones I
would rule out stuff that fails when they fail, not beforehand suppose
they won't work.

--
Felipe Monteiro de Carvalho
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Language constructs and types that dependent upon system unit

noreply
In reply to this post by gabor-10
On Thu, January 19, 2017 1:28 pm, gabor wrote:
> I was hoping that maybe there is an easy answer. But I understand.
> Thanks.
>

The easy answer is just to use the system unit and have no fear...

The main issue with using fpc with C is when you try to use classes or try
to use C++ classes

As objects are not so portable across languages.. Every language has their
own object format.  Also strings, being reference counted, will cause some
issues unless you convert them to pchar when sending in as a read only to
C, or if C writes to the string buffer you have to send a buffer in that
is allocated by you (or a fixed buffer) rather than sending in an
Ansistring. Memory managers will conflict.  Or use shared memory manager.
But C knows nothing about what a modern pascal reference counted
ansistring is.. it has no information about it.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Language constructs and types that dependent upon system unit

noreply
In reply to this post by gabor-10
Forgot to mention,  you can also write your own system unit and swap it in
place (in delphi and fpc).  You can modify existing system unit or even
rewrite your own system unit from scratch..

KOL/mck project does this sort of thing to decrease executable size to a
miniature size. Embedded programmers sometimes write their own system unit
too, for size constraints or special situations on embedded systems.

So don't feel that you are limited to the system.pp unit that you are
provided with delphi for fpc, as you can modify it... or even rewrite it
from scratch (not for faint of heart, but Kol/mck does something like it)

On Thu, January 19, 2017 1:28 pm, gabor wrote:

> I was hoping that maybe there is an easy answer. But I understand.
> Thanks.
>
>
> Michał.
>
>
> W dniu 2017-01-19 o 20:28, Jonas Maebe pisze:
>
>> It is therefore not possible to give an answer to your question that is
>>  generally valid. Furthermore, the answer could become wrong at any
>> time because all of that is implementation-dependent.
>>
>>
>> Jonas
>>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Language constructs and types that dependent upon system unit

gabor-10
This significantly complicates my project. I would avoid this.
After a few tests, I can say that it works correctly with the linked
system unit and cmem. Unfortunately, this greatly complicates build
process which is disproportionate to amount of code. So I decided to do
it in C for now.

Thanks.
Michał.

W dniu 2017-01-22 o 08:01, Lars pisze:
> Forgot to mention,  you can also write your own system unit and swap it in
> place (in delphi and fpc).  You can modify existing system unit or even
> rewrite your own system unit from scratch..
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal