Mail #5265

Back to main page of archive

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

From: Marco van de Voort
Subject: Good version for mostly IT activity
Date: 22 Jul 2001, 15:37:57

> Marco van de Voort wrote:
> 
> > >I did not try that one - for me compatibility with
> > > standard library and ease of linking with c, c++ is important.
> > 
> > FPC can link with c and C++.
> 
> I think one main issue is type compatibility, i.e. can you be sure
> that, say `int' in C always matches `Integer' in Pascal in size --

I don't see why this would have be like that. I already use special 
identifiers (like Cint Clong etc) in all my headers for a decade, from 
my M2 times.   

I include a ctypes.inc in each header file. Till now this is not 
standard (I have to implement that file for each platform, but if FPC 
starts to support 64-bits processors, it could be supplied with each 
target, we are talking about plusminus 6-10 types here)

Pascal's typing will save you from errors, as long as you are 
consequent. Side benefit of this is that you can use a different 
programming model if desired.  (e.g. if you major use is to interface 
with an application/system that uses a different convention than 
C/GCC). So you can be LP64 in an ILP64 world.

If you map 1:1 you are stuck with what C does, even it is difficult.

> otherwise (if that depends on the platform), translations of C
> headers would be bound to a particular platform.

Or would need a 5 minute global replace before work can really 
start? As long as I'm consequent (translate C-int with longint  etc) I 
can reverse the process.

> > FPC or GPC depends on your task and system.  In general:
> > - Non x86? Then GPC. (m68k FPC in beta) 
> 
> So maybe this issue hasn't arisen yet for FPC, 

It hasn't arisen directly, but we also read C faqs from time to time.
I also know about endianess, alignment etc :-)

We have to implement a n-bit clean CG from scratch, and I'm sure 
we can handle such details in the RTL.

>but if I'd translate
> a header now, I'd also want to know if I'll have to do it again on
> each platform ...
[evil mode on]

Hmm, substitutions are not necessary. FPC supports qualified 
identifiers.

{$ifdef 64bit} {not complete}
type longint=System.int64;
	 shortint=System.longint;
       int64=System.int128;			{problem. int64 is used as "long 
long", but int64 as type could exist in C too)
{$endif}	
[evil mode off]

I had the problem with int64 above already years ago under Modula-
2 (where "CARDINAL" is a base type, which also exists under C. I 
had a 16-bit M2 (M2-CARDINAL=16-bit), and interfaced to DJGPP 
written structures (CARDINAL=32-bit)

It is the reason why I keep C and Pascal types strictly apart, and 
prefix c types with "c" in headers. Typing saves the day again :_)

In general, 64-bit problems were not that bad as I expected. This is 
probably due to the average lower use of pointers (specially strings), 
and cleaner code in Pascal.

I think endianess and alignment causes much more problems (when 
porting old x86 codebases to other processors) long term than 64-bit 
problems, specially for people that need cross platform binary 
compability from time to time. How does GPC deal with that?

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

In reply to

Back to main page of archive

Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.

Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.

This page was created by Crystal 0.999 (Linux 2.4.27/i686).