[fpc-devel] Porting FPC to IBM zArch

Jonas Maebe jonas.maebe at elis.ugent.be
Wed Jul 24 10:02:50 CEST 2013


On 24 Jul 2013, at 03:41, Bernd Oppolzer wrote:

> I'm a new member on the fpc-devel mailing list.

Welcome.

> I would like to know, if there are still some efforts going on to
> do a port of FPC on IBMs z architecture. There has been some work
> in this area, although somewhere in the FPC wiki there are statements
> that there will be probably no port to IBM z.

No such efforts are currently underway afaik.

> Another issue is the character set: in the EBCDIC case there are gaps between
> the alphabetic characters, so you have to code - for example:
> 
> if ch in (. 'A' .. 'I', 'J' .. 'R', 'S' .. 'Z' .) then begin ... end;
> 
> but this works for an ASCII based compiler as well.
> 
> I looked at fpc/compiler/scanner.pas and saw some source parts using
> 
> ch in (. 'A' .. 'Z' .)
> 
> which should be changed to a function call like isupper (ch) etc,
> where the dependencies of the underlying character set should be handled,
> but IMO there are not many places where the compiler is really dependent of
> the character set.

Such changes would only help if you would also convert the compiler's source code to EBDIC and tell the compiler compiler that this is the case, otherwise the (. 'A' .. 'I', 'J' .. 'R', 'S' .. 'Z' .) would still be interpreted as ASCII and hence be transformed in exactly the same code as it is now. The proper way to solve this is not to change the tests in the compiler source code (you would get a compiler that would only be able to parse either EBDIC or non-EBDIC source code), but to add EBDIC support to the compiler/scanner in a way that performs the translation to ASCII (or UTF-8, to keep EBDIC characters that cannot be represented in ASCII) before the characters are interpreted. This is different from the current code page support, which only translates string and character constants.

> There are some minor problems I faced when compiling the Stanford Pascal
> sources with FPC:
> 
> - Stanford Pascal (my version) allows (. .) and (/ /) as substitutes for [ ]

FPC also supports (. and .). It doesn't support (/ and /) though. Support for that could maybe be added under a new syntax mode or mode switch switch, but is this a common syntax? I've never heard of that one before.

> - and -> for the pointer symbol  (like VS/PASCAL)

Adding support for that under a syntax mode or mode switch switch should be no problem.

> - and different styles of comments:
> 
> { }
> (* ... *)
> /* ... */
> and - strange to me, but it's in the compiler source: "this is a comment, too"

FPC supports the first two styles. Maybe the rest could be added, but that seems very un-Pascallish.

> Comments of different types can be nested;
> comments of the same type can be nested, if the compiler option N+ is set.

FPC supports nesting of {} comments. (* *) comments do not nest, and { } comments appearing inside (* *) comments are ignored (they don't start a new nesting level). Supporting four nestable comment would require quite a few changes and I'm not sure whether this would be nice. Are these also extensions that you added yourself?

> The new statements break, continue and return were also present in VS/PASCAL, IIRC,
> and they work much the same way as their C counterparts. Because I added them in 2011,
> they are of course not present in the compiler source.

FPC supports these already ("return" currently only in Mac Pascal mode, but that can be easily changed).

> What do you think of those extensions?
> 
> If you would, for example, accept one or more of those suggestions, I would enjoy helping
> you to implement those extensions in FPC, once I got more insights in the internal structure
> of the compiler (in some months or so).

I think that adding support for -> under a syntax mode switch (m_stanford ?) is probably ok. You can look at the existing scanning of (. to see how it's done (scanner.pas around line 4210 in svn trunk). The tmodeswitch type can be found in compiler/globals.pas. You just have to add a new enum there and a corresponding string in the modeswitchstr constant array.


Jonas


More information about the fpc-devel mailing list