Hello,

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

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.

Anyway, I would like to do some work on this. In 2011, I ported an extended version of the Stanford compiler (the McGill version from 1982, with some maintenance done in 2007) from MUSIC/SP to VM/370 R6 on Hercules
- an IBM 370 emulator - and then I did some extensions to it, including new language elements (new statements break, continue, return and new comment styles, some 2-byte char representations that VS/PASCAL had, for example -> for the pointer symbol etc.) and I fixed some year-2000-issues.

When trying to port this compiler to OS/2 and Linux, I observed some character
set problems. I didn't complete this due to limited time.

Today I ported a pretty print tool which is part of this environment without problems
using FPC on Windows. The only issue was that the scanner had to be changed,
because on Windows it reads the linend characters 0x0d and 0x0a, where on the
IBM mainframe there are no lineend characters (the runtime sends blanks to the
Pascal program at line end).

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.

My roadmap is:

- first I would like to port the Stanford compiler to Windows, OS/2 and maybe Linux 386,
using FPC. Only phase 1, which generates PCode. My goal is not to get a compiler
which produces executable code, but to learn about the issues when porting an EBCDIC
compiler to an ASCII machine, in the first place. This is of course much easier than the
other direction (FPC to zArch), because the compiler is much smaller.

- when I completed this, I would like to experiment with FPC, trying to build a compiler
from the source tree, for a new target CPU and OS, that is, IBMZ. I know enough about
IBM machine code, ASSEMBLER, opsys and run time systems. In contrast to the discussions
that I saw already (targetting zLinux with ASCII codebase), I plan to build a FPC compiler
which works on BOTH codebases - I want to know, where the issues are.

There are some minor problems I faced when compiling the Stanford Pascal sources with FPC:

- Stanford Pascal (my version) allows (. .) and (/ /) as substitutes for [ ]

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

- and different styles of comments:

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

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

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.

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).

If you want, you can contact me offline, to discuss some details further. My native language is German.

Kind regards

Bernd

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.

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.

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).

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

Hi Bernd, glad to see you've joined this ML.

Obviously my experience of both the IBM architecture and the innards of FPC is limited, but my opinion is that the only achievable goal is to first concentrate on ASCII, and later port to EBCDIC since this could result in significant changes to the compiler frontend etc. However, I'll obviously defer to consensus.

Normally, migrating ASCII sourcecode (be it C or Pascal) to IBM z is no big deal; you transfer the source to the mainframe by textmode FTP or similar tools, and everything works fine.

With C in the 90s, there were some issues, because the C operator characters were at strange places in the different national character sets. Sometimes you had to use so called trigraphs, for example ??< for {, but today you put a #pragma in front of the specific source code, specifying the char set (if you have sources in different char sets, for example, which take part in the same build) and everything works fine. You can use {, [ etc., the same way as on the PC, and customized to your national flavor of EBCDIC, be it US-american or german (even the exclamation mark, which is "NOT" in C, is at different places in the char set in US-EBCDIC and german EBCDIC, which was a big issue in the 90s - no more today).

With Pascal, this should not be an issue at all, because we don't have so many strange characters in the source char set like ~, \, | etc.

The only issue IMO are such things that I mentioned already: char set range conditions. Big endianness is already solved, because you have already big endian targets. I don't see any non solvable problems.

Of course, you are right: in the end the compiler needs a charset option, and the function that feeds the scanner with source lines has to do the translation from EBCDIC to ASCII, for example. The compiler in its internal logic remains ASCII.

I have some experience on such topics, for example: I wrote a very fast lightweight XML parser for a customer of mine, which outperforms the other XML parsers by a factor of 3. It runs on the IBM mainframe and on Unix, Windows, OS/2 (which I still use as development platform). Same code base for all platforms. There I have these issues, too.

Let's see. Migration of FPC compiler sources to the mainframe is one of the later steps in my project. First of all, I have to gain more experience with FPC. I would like to tell you all, that I am very impressed about the size and the quality of this software - very good work!

Yesterday, for example, I observed that even writeln (s); for scalar types s is supported - which IMO was not the case for older Pascals - very convenient for quick tests ...

Kind regards

Bernd

Jonas Maebe wrote

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.

Jonas Maebe wrote

> 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?

You're sure regarding (* *) comments?

=== code begin ===

program test;

(*
comment 1
(*
comment 2
(*
comment 3
*)
*)
*)

begin
end.

=== code end ===

=== compile output begin ===

PS P:\tests\oneshots> fpc -Mobjfpc commenttest2.pas Free Pascal Compiler version 2.6.0 [2011/12/25] for i386 Copyright (c) 1993-2011 by Florian Klaempfl and others Target OS: Win32 for i386
Compiling commenttest2.pas
commenttest2.pas(5,3) Warning: Comment level 2 found commenttest2.pas(7,3) Warning: Comment level 3 found Linking commenttest2.exe
14 lines compiled, 0.1 sec , 25920 bytes code, 1644 bytes data 2 warning(s) issued

=== compile output end ===

Regards,
Sven

You should split this into two steps (which is the usual approach):
- first create a cross compiler; thus a compiler which compiles Pascal programs for IBMZ. This way you can implement the RTL and do testsuite runs
- once the cross compiler and the programs it compiles runs satisfactory you can try to compile the compiler for IBMZ

You'll also need either cross binutils (e.g. i386-linux -> whatever-ibmz) (containing "as" and "ld") or you'll need to write your own assembler writer and a linker (or you'll need to use "assemble on target" option). For the first step the first variant is suggested. On the IBMZ itself you'll also need to have binutils available except you decide to use an internal assembler/linker.
Note: you don't necessarily need GNU assembler and linker, but otherwise you'll need to write support for it in the compiler.

Regards,
Sven

Bernd Oppolzer wrote

Yesterday, for example, I observed that even writeln (s); for scalar types s is supported - which IMO was not the case for older Pascals - very convenient for quick tests ...

Free Pascal has vast extensions compared to older Pascal dialects. I suggest you to take a look at the language reference guide for an overview of the current feature set of FPC 2.6.2:
http://www.freepascal.org/docs-html/ref/ref.html (trunk has some more improvements)

On a related note to Writeln:
- writing enum names is also supported (e.g. Writeln(True) will print TRUE)
- writing to a String (known from ISO Pascal) is also supported: WriteStr(s, 'Hello World!', 42) (String s will then contain 'Hello World!42')

Regards,
Sven

Some answers to some questions below:

- the (/ /) substitute for [ ] was the only available substitute in the original Stanford compiler (which, BTW, is the Pascal P4 of Niklaus Wirth). I added (. .), because this was present in my sources. Same goes for ->, Stanford supported @ only (IIRC).

- the N+ option for nesting comments was already present in the Stanford compiler,
but IIRC, it worked only for { } comments. I added the /* ... */ comments - which could
be dropped again, if you don't like it - and the support for nesting the other comment types.

My existing Pascal sources ran successfully on PASCAL/VS (IBM mainframe compiler)
in the 90s, so my goal was to extend the Stanford compiler in such a way that I don't
have to change my PASCAL/VS sources (much).

Kind regards

Bernd

Oh, so it is already implemented :-)

same here:

TOF:
1 LINE # D/NEST LVL < STANFORD PASCAL, OPPOLZER VERSION OF 10.2011 > 12:07:15 07-24-2013 PAGE 1

         1           ) program DECOD ( INPUT , OUTPUT ) ;
         2           ) (*$N+*)
         3           ) var I : INTEGER ;
         4    356D  1)     C1 : CHAR ;
         5    357D  1)     C2 : CHAR ;
         6    358D  1)     CH : CHAR ;
         7    359D  1)     HEX : packed array [ 0 .. 15 ] of CHAR ;
         8    375D  1)
         9    375D  1) BEGIN (* HAUPTPROGRAMM *)
        10           ) (* A (* B (* C *) *) *)
        11           )   HEX := '0123456789ABCDEF' ;
        12      1N  1)   I := 0 ;
        13      1N  1)   while not ( EOF ( INPUT ) ) do

the (*$N+*) comment switches on the nested comment option

in line 10 you can see a nested comment using (* ... *)

no warnings

it looks a bit archaic, but remember: it is a compiler which has it's origin in the 1970s.

Kind regards

Bernd

Minor warning: in FPC etc. @ is the "address of" operator.

I'd suggest avoiding (/ /) as comments.

Vector Pascal allows e.g. \+ as a reduction-addition operator, if FPC ever considered implementing anything like this it would be desirable to have \ and / unencumbered.

http://www.dcs.gla.ac.uk/%7Ewpc/reports/compilers/compilerindex/vp-ver2.html

minor correction: the substitute (/ /) is for array indices [ ], not for comments.

This looks like a matter of taste, but if there were significant amounts of legacy source code using this, this could be of concern.

(I don't know, if this is the case - I have such programs, because (/ /) was
allowed in some old Pascals including the descendents of the Wirth compilers -
Stanford, VS/PASCAL of IBM and the one that we had at the Stuttgart university
in the late 70s / early 80s on the Telefunken TR 440 - probably no one here will know this machine and the opsys BS3 - I was only 18 years old when I started
Pascal programming on this machine, today I'm 54).

-> is a substitute for the pointer symbol; other symbols used for this are ^ and @

Kind regards

Bernd

In FPC you can use

{$modeswitch nestedcomments}
or
{$modeswitch nestedcomments+}

to switch them on and

{$modeswitch nestedcomments-}

to switch them off.

They are enabled by default in the modes fpc (default mode) and objfpc. The modeswitch directive can only be used at the beginning of a program/unit though (basically till before the uses section is parsed).

Regards,
Sven

Hmm... I like the idea of array operators :) Could be added as an additional modeswitch to avoid backwards compatibility problems with overloaded operators for arrays...

Regards,
Sven

Sorry, I'm sure, this is a very basic question,
just to speed up things a little ...

when I run the compiler on Windows on my test sources, everythings works fine.

Now I wanted to build executables for OS/2 and Linux-386, just to learn more about cross-compile. But the installed compiler-exe (which came with Lazarus) only supports the win32 target.

The compiler message is as follows:

C:\fpc_test>ppc386 -Tos2 pasform.pas
Free Pascal Compiler version 2.6.2 [2013/06/09] for i386 Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: OS/2
Compiling pasform.pas
Fatal: Can't find unit system used by PASFORM
Fatal: Compilation aborted

Same goes for -Tlinux

Of course, I have to build a new compiler. Or: do I misinterpret the error message?

I downloaded the development tree using svn.

What is the easiest way to build a new compiler, and: will it be possible to build a compiler that is able to build different targets at the same time?

Kind regards

Bernd

APL- where a lot of this comes from- uses / for reduction (knocks a dimension off, e.g. the total of the numbers in a list) and \ for scan (e.g. the running total of a list). I think it's desirable to avoid \ because of its legacy as an escape in unix, some sort of efficient reduction is obviously a bit of a hot topic because of Google "map-reduce" etc.

With the compiler as it stands, I've been able to define e.g. <variant>
+ <dynamic array>, define a variant constant "reduce", and then do e.g.

  a := reduce + b  where b is an array. Which was all fine except that

(at least when I last looked) there wasn't a compact notation for initialising a dynamic array, i.e. no b := (1, 2, 3, 4).

The problem is not the compiler. Each compiler can compile for each target of the supported platform. E.g. an i386-win32 compiler can also compile for i386-os2 and i386-linux. It can not however compile for e.g. x86_64-win64 or powerpc-linux.
What is not provided by default for other targets is the RTL (and FCL and packages) which the compiler needs to compile programs. These you need to create by yourself, but for this you'll also need the according binutils and depending on the target platform and your program also libraries from the platform (e.g. when you compile for Linux systems). Cross compiling for different combinations is described here: http://wiki.freepascal.org/Cross_compiling
In the simplest cases the approach mentioned for Win32 -> Win64 is sufficient, but you should also take a look at the BuildFAQ: http://wiki.freepascal.org/buildfaq

Regards,
Sven

Interesting idea to "misuse" a Variant for that :)

If you have a named dynamic array type then you can use "TMyArrayType.Create(1, 2, 3, 4)", though this only exists in Trunk (reason: Delphi compatibility). My idea was to implement a Pascal like way for this somewhen which would use "b := [1, 2, 3, 4]" (because in code sections arrays are normally done using "[...]" instead of "(...)" (which is used in constant sections)).

Regards,
Sven

Sven Barth wrote:

We're heading off topic, no disrespect to Bernd intended.

It was the only numeric type I could get to work that way, but I didn't try e.g. a type defined as an empty record which might be more appropriate.

[Nod] Yes, the hack I described above was done at about the time we were discussing that sort of thing which was also when I came across Vector Pascal... which actually has some nice ideas.

Thank you very much.

I succeeded in building a new compiler from the SVN sources, and it runs successfully for the win32 target.

C:\fpc_test>ppc386 pasform.pas
Free Pascal Compiler version 2.7.1 [2013/07/24] for i386 Copyright (c) 1993-2013 by Florian Klaempfl and others Target OS: Win32 for i386
Compiling pasform.pas
pasform.pas(746,8) Note: Local variable "CH" not used pasform.pas(1147,8) Note: Local variable "I" not used pasform.pas(1411,11) Note: Local variable "EINRUECKSAVE" not used pasform.pas(1405,8) Note: Local variable "EINRUECKS2" not used pasform.pas(1981,8) Note: Local variable "I" not used pasform.pas(118,5) Note: Local variable "INCSTATE" is assigned but never used
pasform.pas(121,5) Note: Local variable "KPINDEX" is assigned but never used Linking pasform.exe
2197 lines compiled, 0.1 sec, 48208 bytes code, 1220 bytes data 7 note(s) issued

and the program works as expected.

Then I built the RTL for linux, which also worked successfully, as far as I saw,
but when compiling with -Tlinux, I now get the following message:

C:\fpc_test>ppc386 -Tlinux pasform.pas
Free Pascal Compiler version 2.7.1 [2013/07/24] for i386 Copyright (c) 1993-2013 by Florian Klaempfl and others Target OS: Linux for i386
Compiling pasform.pas
PPU Loading C:\fpc\rtl\units\i386-linux\system.ppu PPU Invalid Version 135
Fatal: Can't find unit system used by PASFORM
Fatal: Compilation aborted

that is: the system.ppu seems to be found, but there is something wrong with the version.

When trying to build the RTL for OS/2 (running make in the os2 subdir of fpc/rtl), I get the following messages:

C:\fpc\rtl\os2>make
C:/lazarus/fpc/2.6.2/bin/i386-win32/gmkdir.exe -p ../../rtl/units/os2 i386-os2-as -o ../../rtl/units/os2/prt0.o prt0.as
process_begin: CreateProcess((null), i386-os2-as -o ../../rtl/units/os2/prt0.o p
rt0.as, ...) failed.
make (e=2): Das System kann die angegebene Datei nicht finden. make: *** [prt0.o] Error 2

apparently, there is no i386-os2-as

when I did the same thing in the linux subdir, it worked (but: see above).

Do I need a special ASSEMBLER to build the OS/2 RTL?

Is it possible to download a pre-built OS/2 RTL?

No need to invest much time in those questions: I already had some insights in the techniques of cross-compiling ... and in any case I'm now able
to build a new compiler from the compiler sources.

Kind regards

Bernd

no problem at all :-)

Mark Morgan Lloyd wrote

Sven Barth wrote: We're heading off topic, no disrespect to Bernd intended.

Bernd Oppolzer wrote

Then I built the RTL for linux, which also worked successfully, as far as I saw, but when compiling with -Tlinux, I now get the following message:

How did you build it? Building the RTL for Linux should be (assuming that your FPC source is at c:\fpc)

cd c:\fpc
make crossall CPU_TARGET=i386 OS_TARGET=linux
CROSSBINDIR=C:\path\to\linux\binutils BINUTILSPREFIX=i386-linux-

BINUTILSPREFIX could also be something different or empty (then the option should be "BINUTILSPREFIX="), it depends on how your assembler/linker for Linux is prefixed.

Once that worked you can install the compiler using

make crossinstall CPU_TARGET=i386 OS_TARGET=linux
INSTALL_PREFIX=c:\wherever\fpc\should\be\installed

You should do a

make all install INSTALL_PREFIX=c:\wherever\fpc\should\be\installed

at first though. You'll also need to adjust a configuration for your new compiler (simplest approach is to copy the fpc.cfg from c:\whereever\fpc\2.6.2\bin\i386-win32\fpc.cfg to
c:\wherever\fpc\should\be\installed\bin\i386-win32 and adjust it)

You compiled the RTL using the 2.6.2 compiler, not the 2.7.1 compiler. The PPU version of 2.7.1 is already > 160.

When trying to build the RTL for OS/2 (running make in the os2 subdir of fpc/rtl), I get the following messages: C:\fpc\rtl\os2>make

This is wrong. You need to build at the toplevel which is c:\fpc\rtl. Everything else is not officially supported and not recommended for a beginner (no offence).

(Note: You'd need to pass the path to the new compiler otherwise it will just use "fpc" or "ppc386" which will use your installed fpc; this can be done using the FPC option like this:

make clean all FPC=c:\wherever\ppc386.exe

)

You'll need to either find binary assembler and linker for OS/2 or build it yourself. As I don't normally cross compile to OS/2 I can't help you here.

You could try to use the RTL provided with the native OS/2 package, but you'd still need an assembler and linker to compile a program.

No need to invest much time in those questions: I already had some insights in the techniques of cross-compiling ... and in any case I'm now able to build a new compiler from the compiler sources.

Regards,
Sven

PS: Please don't post at the top, but at least answer below the previous mail or better use inline answers (like I did here). Thank you.

Is it possible to "ask" the makefile for the true names of the supported targets?

Huh? What do you mean with "true names" and "supported targets"?

Regards,
Sven

On Wed, July 24, 2013 16:36, Bernd Oppolzer wrote:

Hello Bernd,

.
.

Free Pascal Compiler version 2.7.1 [2013/07/24] for i386 Copyright (c) 1993-2013 by Florian Klaempfl an When trying to build the RTL for OS/2 (running make in the os2 subdir of

fpc/rtl), I get the following messages:

C:\fpc\rtl\os2>make C:/lazarus/fpc/2.6.2/bin/i386-win32/gmkdir.exe -p ../../rtl/units/os2

i386-os2-as -o ../../rtl/units/os2/prt0.o prt0.as

process_begin: CreateProcess((null), i386-os2-as -o ../../rtl/units/os2/prt0.o p rt0.as, ...) failed.

.
.

First of all - I'm maintainer of the OS/2 target in FPC, but I'm on vacation now (until end of this week) and thus somewhat slower in reading and replying e-mails and also limited due to having no PC (and no electricity ;-) ) around.

Now to your questions: OS/2 RTL (and compiler, text mode IDE, etc.), are obviously available for download and installation (primarily under OS/2, but there are ways how to use and unpack this package on other platforms - MS Windows would be probably the easiest one due to using the same directory structure (different on Unix targets) and ability to run the GO32v2 (aka DOS) installer which can install the OS/2 releases too. One important caveat in this case - OS/2 releases use the short version of target (only "os2" instead of "i386-os2", "win32" instead of "i386-win32", etc.), in order to allow use of FPC also with OS/2 installed on FAT-16. This means that you need to rename directory "units\os2" to "units\i386-os2" or create a NTFS symlink accordingly when trying to use the Win32 compiler targetting to OS/2. Obviously, you need to use the 2.6.2 compiler when using the 2.6.2 pre-compiled RTL.

Another caveat - cross-compilation to os2 target are somewhat complicated by missing internal assembler and linker for the OS/2 target and the arcane version of GNU tools (especially the linker and GDB which are only available in the special EMX version derived from GNU binutils version 2.6 long time ago and never merged into the mainstream GNU tree). Cross-compiled binutils exist for the Win32 platform - coming from the RSX NT port if it tells you something. These are available on our FTP server in directory "contrib" (together with cross-binutils for other combinations).

However, the included assembler does not support some newer opcodes and this makes building the FPC RTL impossible with this assembler (a newer port of GNU assembler to OS/2 is available and included with FPC - unlike LD and GDB. This version of GNU assembler featuring the EMX a.out format necessary for the EMX/RSX linker and GDB might be possibly built for Win32 too, but I'm not aware of pre-built binaries.

Cross-debugging from Lazarus would probably not work either (remember the legacy GDB version) - GDB and PMGDB as included with the OS/2 release need to be used for debugging of OS/2 binaries compiled with FPC.

I can imagine that using OS/2 for cross-compiling to potential future zArch target due to out of the box support of EBCDIC character set in OS/2 (once I finish the OS/2 widestring/unicodestring manager ;-) ) and I'm willing to help you with any potential obstacles with the os2 target as much as possible.

Hope this helps

Tomas

On Wed, July 24, 2013 16:36, Bernd Oppolzer wrote:

Hello Bernd,

.
.

Free Pascal Compiler version 2.7.1 [2013/07/24] for i386 Copyright (c) 1993-2013 by Florian Klaempfl an When trying to build the RTL for OS/2 (running make in the os2 subdir of

fpc/rtl), I get the following messages:

C:\fpc\rtl\os2>make C:/lazarus/fpc/2.6.2/bin/i386-win32/gmkdir.exe -p ../../rtl/units/os2

i386-os2-as -o ../../rtl/units/os2/prt0.o prt0.as

process_begin: CreateProcess((null), i386-os2-as -o ../../rtl/units/os2/prt0.o p rt0.as, ...) failed.

.
.

First of all - I'm maintainer of the OS/2 target in FPC, but I'm on vacation now (until end of this week) and thus somewhat slower in reading and replying e-mails and also limited due to having no PC (and no electricity ;-) ) around.

Now to your questions: OS/2 RTL (and compiler, text mode IDE, etc.), are obviously available for download and installation (primarily under OS/2, but there are ways how to use and unpack this package on other platforms - MS Windows would be probably the easiest one due to using the same directory structure (different on Unix targets) and ability to run the GO32v2 (aka DOS) installer which can install the OS/2 releases too. One important caveat in this case - OS/2 releases use the short version of target (only "os2" instead of "i386-os2", "win32" instead of "i386-win32", etc.), in order to allow use of FPC also with OS/2 installed on FAT-16. This means that you need to rename directory "units\os2" to "units\i386-os2" or create a NTFS symlink accordingly when trying to use the Win32 compiler targetting to OS/2. Obviously, you need to use the 2.6.2 compiler when using the 2.6.2 pre-compiled RTL.

Another caveat - cross-compilation to os2 target are somewhat complicated by missing internal assembler and linker for the OS/2 target and the arcane version of GNU tools (especially the linker and GDB which are only available in the special EMX version derived from GNU binutils version 2.6 long time ago and never merged into the mainstream GNU tree). Cross-compiled binutils exist for the Win32 platform - coming from the RSX NT port if it tells you something. These are available on our FTP server in directory "contrib" (together with cross-binutils for other combinations).

However, the included assembler does not support some newer opcodes and this makes building the FPC RTL impossible with this assembler (a newer port of GNU assembler to OS/2 is available and included with FPC - unlike LD and GDB. This version of GNU assembler featuring the EMX a.out format necessary for the EMX/RSX linker and GDB might be possibly built for Win32 too, but I'm not aware of pre-built binaries.

Cross-debugging from Lazarus would probably not work either (remember the legacy GDB version) - GDB and PMGDB as included with the OS/2 release need to be used for debugging of OS/2 binaries compiled with FPC.

I can imagine that using OS/2 for cross-compiling to potential future zArch target due to out of the box support of EBCDIC character set in OS/2 (once I finish the OS/2 widestring/unicodestring manager ;-) ) and I'm willing to help you with any potential obstacles with the os2 target as much as possible.

Hope this helps

Tomas

You're telling him that it's possible to build using ...CPU_TARGET=i386 OS_TARGET=linux but where do those come from? Without being told by a developer or without referring to fully updated documentation, how does somebody know to use "i386" rather than "x86", or whether it should be "mips" or "mipseb"?

I can see that there's a MAKEFILETARGETS list in the makefile, which obviously goes slightly further than I'm asking in that it shows the valid combinations (i.e. somebody trying to build for powerpc + os2 is severely out of luck). But something like a "targets" target would be useful.

He/she doesn't know. Simple as that. If you want to build for a different target than your host one you should inform yourself anyway, because there are only very few combinations (i386-win32 -> x86_64-win64, i386-* -> i386-nativent, x86_64-linux -> i386-linux on multilib systems) which work out of the box. For everything else you need binutils, sometimes libraries, etc.

Well... open a feature request...

Regards,
Sven

http://bugs.freepascal.org/view.php?id=24789

Is the Stanford compiler related to P4, since I notice that a port of P4 to FPC/Delphi has just been published on Berlios
https://developer.berlios.de/projects/pp4fpc/

My previous message to this group was sent erroneously.

I absolutely hate when it does that; I wanted to paste something into a message and it took that as a "send" request instead of pasting the text into the message. To prevent that, I'm not putting anything in the TO address until I'm ready to send it, locking the system and preventing it from misinterpreting me as transmitting a message I wasn't ready to send.

Anyway, I wrote to Bernd Oppolzer first, because I want to see full FPC made available on the 370, possibly the zSystem and find out if he's interested in getting involved in this.   So I need to ask: how can I get this? I originally wrote this group more than a year ago on the subject, then realized that I couldn't figure out what was going on without a reasonable cross-reference program, only to find there's nothing that's been done that can handle the UNIT statement or {$IF} and {$DEFINE}/{$IFDEF} statements.

So I came to realize I need to ask two things. How to get the flags and hooks added to the current sources and how do I enable any of the big-endian ports of FPC to cross-compile on Windows? (I do not want to have to put up a Linux box when I already have a copy of FPC running. The compiler is going to be text mode, of course, so I either don't need Lazarus or can't compile it and wouldn't anyway.)

I've been busy, I have other things I had to attend to, then I realized I couldn't figure out what was going on without a decent cross reference program, but nothing that's out there supports the UNIT construct, nor do they know how to skip over {$DEFINE} {$IF} {$ELSE}, and so I stopped to write one and I was busy with the work on that. I'm having trouble there, so I set it aside. Anyway, I came back and realized if I can get one of the Big Endian ports working I can just figure out what files it uses and then edit those to change the generated assembly language and/or the object files if it makes object files the way the Pascal 8000 compiler for the 370 from the Australian Atomic Energy Commission did back in the late 1970s and early 1980s did.

There are two things I'd like to find out to determine how it might be possible to get Free Pascal ported to the s370 series.

First, I want to add some of the compiler flags I mention in the description of my attempts on the WIKI to add the s370 and/or zSystem architecture, how do I get those flags - they do not break the build - added as hooks to the compiler sources so that eventually a {$DEFINE S370} statement can be added to get the compiler to build itself for the 370 (and possibly other defines depending on the machine and OS target}? There will eventually need a new directory for the files that the 370 and whatever OSs it uses supports, but, again, that's months away. I have to start over, and I have to start somewhere.

I know FPC makes better "write once, run anywhere" code capability than Java will ever touch. I wrote an application for 64-bit Windows 7 that a customer needed. I took that same code over to a 32 bit PPC Macintosh running OS X 4.11 and the same program ran without change to the source code other than that the fonts are larger on the Mac so I had to shrink them a little to make the window fit. But the same unmodified code worked exactly the same on two different machines, two different operating systems, two different architectures. I have no doubt it would do the same thing re-compiled for Linux, without change.

I did another program
where I used compile-time switches to set the values in a checkbox, and when I ran that program on Windows 7, it confirmed it's running Windows on an Intel little-endian 64-bit machine. The exact same unmodified program when compiled and run on my Mac and set the checkboxes in a window that told me it's a 32-bit big-endian BSD Darwin machine.

So, quoting from the commercials from US-based Wachovia Bank after it ate First Union Bank before it itself became digested by Wells Fargo Bank, "Let's get started."

So how would I get the constants and values added to include the s370 as a target for FPC? Would I submit them as a bug fix request as a patch through bugs.freepascal.org on Mantis or something else? I want to reserve a definition number for that processor, at least for now so it has a fixed identifier so eventually it can have its own PPU files and everything else in the toolchain.

Second, how do I create a cross-compiler that runs on Windows, for any of the big-endian processors, so that I can see what it has to generate code for the target machine? Given that, I can change the code to either change the generated object file - if it does direct object files - or the assembly language so it generates S370 assembly.

I can then run the compiler through itself to create a cross-compiler assembly for the 370. Then I can recompile the required modules, then take the assemblies, assemble them with a 370 assembler, producing an actual object module, then run the program against itself and the compiler will at least compile itself. Having done that, I can then create any necessary changes to implement anything needed to provide the equivalent functionality and rebuild the toolchain so it is native to the s370 and units to provide localized services can be created as needed.

I want to see something other than C and Cobol being available as current tools for implementing applications on the z/System mainframe. Maybe even being able to implement CICS transactions in Pascal the way it can be used to create full-blown Windows applications.

Any assistance anyone here can provide will be appreciated. Thank you.

Paul
 
________________________________
The Lessons of history teach us - if they teach us anything - that no one learns the lessons that history teaches us.

I don't get what you're trying to say here.

Analyzing what a big-endian compiler generates won't help you there. You need to look into the compiler's code and learn how it does generate code for a specific platform. That has nothing to do with big endian or little endian.

In FPC there is the frontend which generates a sort of abstract syntax tree on which then the platform specific backend generates code. Thereby the backend provides platform specific nodes for that abstract syntax tree of which then the "generate_code" method is invoked. Platform independant stuff is normally located in the ncg*.pas units and the platform specific stuff is in the nXY*.pas unit of the corresponding CPU directory where XY is a short form of the CPU, e.g. n68kadd.pas for the m68k add/compare node. Best is you look how other CPUs are implemented (prefereably the simpler ones like MIPS or m68k) and copy that more or less for the new platform.

Adding a new platform to FPC is not cheesecake and you should know how the compiler's backend work. Just looking at the output of a target won't help you!

First step is to get a cross compiler to s370/zSystem working so that simple programs can be compiled which you can use to implement the RTL. Only when enough of the RTL is implemented and the code generator works good enough then you can try to cross compile the compiler, but not earlier.

Search the compiler's source for e.g. m68k to see how other platforms are implemented.

No. You should learn how the compiler generates code and then implement a new code generator backend for s370, maybe based on a copy of another platform. Playing around with the output won't help you.

First step consists of cross compiled hello world programs to implement and test the RTL. The compiler is much too complicated to get it running at first.

Regards,
Sven

Sven Barth wrote

Adding a new platform to FPC is not cheesecake and you should know how the compiler's backend work. Just looking at the output of a target won't help you!

A good start is aarch64: I tried to work in it as structured as possible to make it some draft for porting, so have a look at the history of fpc/compiler/aarch64 so you know how to start.

Florian Klämpfl wrote

Am 19.08.2013 10:37, schrieb Sven Barth: > Adding a new platform to FPC is not cheesecake and you should know how > the compiler's backend work. Just looking at the output of a target > won't help you!

I'd hope that Paul isn't naive enough to make that mistake :-) On the other hand, looking at how something like the MIPS compiler was put together could probably be useful.

A good start is aarch64: I tried to work in it as structured as possible to make it some draft for porting, so have a look at the history of fpc/compiler/aarch64 so you know how to start.

Thanks for that, noted. Going back to some of Paul's points though: one thing he's asking is how to get the fundamental hooks added to the invariant part of FPC to allow the target-specific stuff to be put in its own directory. What's best here: for developers to have their own subversion (or equivalent) servers, or for a sandbox to be set up on the public FPC SVN server?

Apropos Paul's comments of doing a good cross-reference and handling compiler directives, I think the thing that is likely to give real problems is the {$if defined() } form... I suppose that it would, at a pinch, be possible to reconstitute the used source from assembler output (-al -s options) but it's the worst kind of hack.

program testpreproc;
const   a= 1;
var     b: integer;
begin
{$if defined(a) }
   b := 1
{$else }
   b := 2
{$endif }
end.

# [5] var.b: integer;
# [7] begin
# [11] b := 2
# [13] end.
# [15]

Apropos Paul's comments of doing a good cross-reference and handling compiler directives, I think the thing that is likely to give real problems is the {$if defined() } form...

I'm not sure whether $if defined() works with ordinary constants. The $DEFINE and CONST identifiers most probably reside in different lists.

This should work better:
  {$if a=1 }

DoDi

I think you're right, but your correction doesn't detract from the point that it is a slightly awkward "crossover case" where it is necessary to do more than simply parse {$ (and, for most cases, (*$ ) lines. I can only think of one other compiler implementation which did this sort of thing, and that was TopSpeed/JPI.

compiler directives, I think the thing that is likely to give real problems is the {$if defined() } form...

I'm not sure whether $if defined() works with ordinary constants. The

$DEFINE and CONST identifiers most probably reside in different lists.

"defined(identifier)" is only for identifiers which were added using "$define", "-d..." or by the compiler itself. If you want to check for the existence of a Pascal identifier use "declared(identifier)".

Regards,
Sven

My version is an extended version of the McGill University compiler of 1982 (which was part of
the MUSIC/SP system), which is an extension of the Stanford compiler of 1979,
which is an extension of Niklaus Wirth's P4 compiler.

Sorry for the late answer; I was off for holidays.

Kind regards

Bernd