Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.
I have to admit first, that I did not read all the comments in this thread. But anyway, I'd like to comment on this. Because I have done Pascal programming for almost 40 years now and even on platforms that are much older than PCs and machines typically run by Unix systems, I have a somehow different view. First of all, there is a good reason why Pascal has a WRITELN procedure; because there are platforms where it is simply not possible to write a special character like 0x0a to flush an output buffer and start a new output line. On old scientific computers of the 1960s and 1970s, there simply was no such character; this comes from the teletype heritage of the Unix operating system. Even today there are platforms (and languages) where it is not possible to write a new line on output simply by writing a 0x0a char. Only people which have grown up with systems like MS-DOS and Unix take this as given. So I doubt that there is a portable solution for multi-line strings in the sense that strings involve carriage-return characters. If you need such things, you have to find non-portable solutions (like platform-specific constants: CONST NL_Number = 0x0a; for example or CONST NL_CHAR = X'0a'; ... if your compiler allow such a notation). Second: To split strings in source programs, I strongly suggest a solution where the parts are terminated on every line; otherwise (with strings left open), you will always have a problem with trailing and leading blanks. The source code should be format free, after all. The simplest solution IMO is: simply close the string on one line and open it on the next one, like here: CONST long_string = 'this is a long string ' 'which occupies ' 'multiple source lines'; if you absolutely need to put line feed characters into such a long string, do it like this: CONST long_string = 'this is a long string ' x'0a' 'which occupies ' x'0a' 'multiple source lines'; This is implemented in my New Stanford Pascal compiler. Kind regards Bernd Am 04.07.2019 um 13:54 schrieb Michael Van Canneyt: On Thu, 4 Jul 2019, Tomas Hajny wrote: On 2019-07-04 12:59, Marģers . via fpc-devel wrote: . . Why introduce ` if there already is ' ? Just use ' as well for multi line strings. For people of more conservative view point, put multilinestring behind mode switch. Because then it's never clear whether the fact that there's no ending quote before the end of the line is an omission, or an intention. Exactly. The same goes for all other quote characters. That's why the directive is a better approach; it is unambigious. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?
FYI: I thought a little bit more about your answer and decided to try it with my Stanford compiler; in fact, your pointer parameter is a VALUE parameter, and because it is copied into the procedure's local stack, it should be treated much like a local variable IMO, and there it is indeed possible to use the ^basetype notation and all the other type notations, too. Therefore IMO it should also be possible to define new types with value parameters, be it useful or not. The normal Pascal assignment rules apply (parameter passing to value parameters is much like normal assignment, with some tolerance regarding types). So I decided to allow it, but for value parameters only. For var and const parameter, different rules apply, because there we have conformant strings for example (strings without length) etc.; so I call a different parsing function, when I have a var or const keyword. Without var or const, I call the same parsing function for types which I call in var declarations etc, too. So now the following program compiles (and runs) without problem: program TESTPTR ( OUTPUT ) ; //** //$A+ //** type CFORW = record SOMEV : INTEGER ; C : -> CHAIN ; end ; CHAIN = record N : INTEGER ; NEXT : -> CHAIN ; end ; var K : -> CHAIN ; X : CFORW ; procedure PRINT ( X : -> CHAIN ) ; begin (* PRINT *) while X <> NIL do begin WRITELN ( X -> . N ) ; X := X -> . NEXT end (* while *) end (* PRINT *) ; begin (* HAUPTPROGRAMM *) NEW ( K ) ; X . C := K ; K -> . N := 1 ; NEW ( K -> . NEXT ) ; K := K -> . NEXT ; K -> . N := 2 ; NEW ( K -> . NEXT ) ; K := K -> . NEXT ; K -> . N := 3 ; K -> . NEXT := NIL ; PRINT ( X . C ) ; end (* HAUPTPROGRAMM *) . - I use a different notation for the pointer symbol; ^ is possible, too - there is no declaration for the -> CHAIN pointer type, nowhere - it is even possible to use it in the CFORW record, prior to the definition of CHAIN (those forward references are checked later) Kind regards Bernd Am 10.06.2019 um 03:26 schrieb Ben Grasset: On Sun, Jun 9, 2019 at 8:37 PM Bernd Oppolzer mailto:bernd.oppol...@t-online.de>> wrote: I am still not sure, if it is a good idea, because this would be an exception for pointer types; other type constructors like arrays, records, enumerations etc. are still not supported ... and it does not make sense IMO to support them. People keep saying this as though the *entire concept *of adding even the smallest new thing syntactically to FPC is a completely new idea (which it obviously is not.) Adding this would *not *be any kind of notable "exception" in any practical sense, unless you're holding FPC to a purely fictional standard for Pascal that it does not actually currently follow in reality. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?
Am 10.06.2019 um 00:28 schrieb Ben Grasset: On Sun, Jun 9, 2019 at 11:26 AM Florian Klämpfl mailto:flor...@freepascal.org>> wrote: Yes, but this has *nothing* to do with the output of -vp. Nothing. My point with that was more just getting at "clearly typed pointer aliases are not actually that big of a deal internally for FPC", as in it doesn't really matter if it *technically* declares a new type. Again, literally nobody in this entire message chain has stated any actual reason why exactly they think it would be specifically *bad* to have `^Type` in method parameters. A compiler writer's point of view: I did something similar recently, when I added types with parameters to my New Stanford Pascal compiler (for example CHAR (15), STRING (25), DECIMAL (15, 2)). I decided to allow this notation in procedure declarations, too. This has the following impacts on the compiler: - you have to parse "type with parameters" in procedure declarations, where you had only type identifiers up to now - you have to construct a new "artificial" type record with a name which is not a normal identifier but which matches for identical notations used later and insert this record into the type list on first occurence. In my case, the types CHAR (n) etc. are standard types, so they are inserted into the type list of the top-level block, even if they occur at lower levels (there is one entry for CHAR (n) for every different value of n, although the CHAR (n) types are compatible to each other to a certain degree, same goes for STRING (n) - CHAR (n) is simply an abbreviation for ARRAY [1..n] of CHAR; STRING (n) are varying length strings, involving a length field). In the case of the pointer notation, things would be different: - a pointer symbol should be accepted in front of the type identifier (or in my case, "type with parameters") - the base type must have been declared already - if there is no definition for this pointer type, also in this case a new "artificial" type record must be built, but the type record should be inserted at the same level as the record of the base type. The generated name should be unique, not a normal identifier, and dependent from the base type identifier. But: I am still not sure, if it is a good idea, because this would be an exception for pointer types; other type constructors like arrays, records, enumerations etc. are still not supported ... and it does not make sense IMO to support them. Kind regards Bernd ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug in macro handling?
No,
if you put a semicolon in there, you will get wrong syntax,
no matter what the datatype is.
Example:
{$MACRO ON}
{$define Fifteen:=15;}
{$define Twelve:=12;}
...
if HDCOUNT0 >= COUNT0 then X := Fifteen
else X := Twelve;
will generate this Pascal statement:
if HDCOUNT0 >= COUNT0 then X := 15;
else X := 12;
and the semicolon before the else is wrong in Pascal syntax.
Remember: $define (macro processing) is stupid text replacement ...
HTH,
Bernd
Am 12.04.2017 um 20:11 schrieb Giuliano Colla:
Il 12/04/2017 19:51, Michael Van Canneyt ha scritto:
Try removing the semicolon:
{$define Positiva:=False}
{$define Negativa:=True}
Without semicolon it works!
Thanks a lot.
BTW, do you think that this holds true only for the define of boolean
values?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug in macro handling?
Hi Guiliano,
I'm no FPC macro language wizard, but in my believe
you are replacing Positiva with False, followed by a semicolon,
and so you get the error from the compiler.
{$define Positiva:=False}
should probably work.
HTH,
kind regards
Bernd
Am 12.04.2017 um 19:39 schrieb Giuliano Colla:
Hi honourable fpc developers!
I found a strange error (both with fpc 2.6.4 and fpc 3.0.0, in Linux
environment)
The following snippet of code:
{$MACRO ON}
{$define Positiva:=False;}
{$define Negativa:=True;}
...
if HDCOUNT0 >= COUNT0 then V_PIU0 := Positiva
else V_PIU0 := Negativa;
gives rise to a Fatal: syntax error: ";" expected but "ELSE" found.
But if I change the code into:
if HDCOUNT0 >= COUNT0 then V_PIU0 := False
else V_PIU0 := True;
(which IMHO should be identical) it compiles without complaining.
Am I doing something wrong or it is a bug?
Giuliano
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Program too long ?
Jonas Maebe schrieb: On 14/01/16 17:45, Mathias wrote: The code is machine generated. I wanted to test which compiler is faster, the. Of FPC or C ++ C ++ could compile the code without errors. Whether or not it can be compiled is unrelated to the language of course, but to the compiler. We indeed only develop FPC for use with procedures that don't have an extreme size, because that way the compiler uses less memory and is faster. Since such massive routines are often indeed only present in case of machine-generated code, and since in that case you can usually easily adapt your generation to split up the code in multiple routines, there's not much incentive to change this (other than being able to say "yes, we can handle this"). Jonas Some history: The original Pascal compiler (Wirth in the 1970s) also had such an error message "procedure too long"; this is a well known issue for almost all compiled languages, and such limits hit you most of the time much earlier than physical limits or storage limits. The very early versions of Turbo Pascal had the problem that the generated code had to fit in a 64 kB segment, so if you wanted to write programs of, say, more than 2000 lines, you had to break it up into several overlays. And this was another kind of restriction, not depending on the size of individual procedures, but on the size of the generated code of all procedures belonging to one overlay alltogether. When designing your overlays carefully, you could write very large programs, but you had to make sure, that calls occured only inside each overlay or from the mainline into the overlay, but not across overlays. So the grouping of procedures into the overlays was tricky sometimes. Pascal/VS on the IBM mainframe threw the error message "procedure too long", when the size of the generated code for the procedure exceeded 8 k, that was the size covered by two base registers. That was about 500 lines only. This way you were forced to split your procedures and functions very eary. But there was virtually no limit on the overall size of the program. Kind regards Bernd ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] OS/2 and DLLs
Am 17.12.2014 22:37, schrieb Ralf Quint: On 12/17/2014 12:38 PM, rpzrpz...@gmail.com wrote: Ralf, Such passion for obsolescence... Thanks! What is the use case other than a hobby and pride for OS/2 support? What ever the user wants to do! Who are you to tell other people what is a valid use case or not?!? And just for your information, OS/2 (now under the name eComStation) is still a commercially available OS (http://www.ecomstation.com/). I am a professional working developer, and I am still using two OS/2 development machines to build software, most of the time written in ANSI C, which is targetted in the end to other platforms like Unixes or z/OS mainframe, but OS/2 still is the development platform I like most. And I use it almost every day. The IBM compilers and debuggers etc. are superb, I also use (old versions of) Oracle and DB2 on this platform and many own - portable - libraries for XML processing, for example, and other interesting tasks. I would like to help Tomas in his efforts, but at the moment I have no time .. maybe next year. Kind regards Bernd But in your case, as good old Mr. Thomas Gray said, "Where ignorance is bliss, 'tis folly to be wise." Ralf --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Multithreading under DOS
Am 26.09.2013 22:33, schrieb Tomas Hajny: How much does the 386 CPU with 2 MB of appropriate RAM cost today? How much power and cooling does it need? How much reliable would be the HW compared to more up to date alternatives (let's say ARM or MIPS with 512 MB RAM and an SSD running Linux)? Anyway, as I mentioned - I can imagine that it may be fun (similarly to my attempts to keep and improve the OS/2 support which is also used very rarely by others at best ;-) ), I just wanted to understand if there was any idea how it would be used in reality. Only for the record: I have two OS/2 machines running - used for developing portable C applications, for example targetting Windows, Unix and IBM mainframes - and I would like to get a version of FPC running there, producing executables for OS/2 and for the virtual DOS boxes inside OS/2, too - if that is possible. But I didn't find the time to do it, so far. On Win XP, everything runs fine, but a cross-compile there with OS/2 target didn't work. Don't know what I missed. Is it possible to build FPC on the OS/2 machines, directly? How could I do that? You could answer me offline, if you like. Kind regards Bernd ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Multithreading under DOS
Am 26.09.2013 11:07, schrieb Tomas Hajny:
Here the old style ("light weight" / "internal" multi-thread enabled)
pthread lib might help. Supposedly same does not need to be "installed"
but could be statically linked to.
You can run another operating system on top of DOS (that's basically what
DOS extenders did), but you still need to find the solution first (and the
solution is not the "POSIX threads library", but the "extender").
Tomas
I believe that DOS from its design is so limited that the only
solution is what OS/2 did: isolate every DOS session and
give it an own - single threaded - copy of a virtual machine,
where DOS can run the old DOS applications.
The POSIX threads should be moved to or implemented on
"real" operating systems.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....
Am 03.09.2013 08:45, schrieb Mark Morgan Lloyd: if you have a language like C which doesn't support nested procedure definitions, it's perfectly simple. You can reach the local (auto) variables using register R13, and the parameters using R1. You only need another register to access the static data and some kind of heap management to support malloc() etc., and that's about all. I believe this sort of thing is also an issue when a function recurses. C supports recursion of functions, and it is without problems possible with the scheme outlined above and in the previous mails. With "classical" 360 machines, you had the problem that the offsets in the machine instructions only were 12 bits long, so you could only address 4 k from the position of a base register directly. That is, if your automatic data (of one procedure) was larger than 4 k, you were in trouble. Data after the 4 k barrier had to be addressed using two steps; first compute the address and the fetch the data - for example. With new z-Arch instructions, this is no problem any more. Same goes for the procedure code itself; PASCAL/VS (an old IBM compiler of the 1980 years) limited the size of procedures to 8 k - which is some hundred lines of source code. This, too, is no problem today any more, because, when you use the new relative branches, you don't need base registers for the code area. Anything that artificially limits function size, or forces the code generator to jump through hoops to work around architecture issues, is a problem /particularly/ when an external tool has automatically generated (Pascal) source. I'm not sure how many people use that technique these days but it was fairly popular in the era when Fortran was dominant, and there are still tools that generate C or Java source. Agreed. But although the limit of 8 k per procedure seems strange from todays point of view, there were significant projects done with this compiler, for example the first TCP/IP stack for the 370 platform in the early 1980s (inside IBM, in Pascal !!). I still have lots of tools generating source code, for example PL/1 and C. XML validator definitions, derived from XSDs (to speed up my XML parser) - well, that's definitions, not executable code, but ocassionnally very large, if the XSD is large - and database access routines ... A language like Pascal, which allows the nesting of procedures and the access of auto variables that are defined outside the local procedure (that is: in procedures above the local procedure), you need to retrieve the stack frame of that procedure first. This is done by walking up the chain of the save areas and load the base address of the stack frame of the interesting procedure into another base register, different from R13 (for example). This is a problem, that a C compiler doesn't have - but it's well known to PL/1, too. This all is very well known and can be derived from the other compilers that deal with the z-Arch environment, for example the IBM commercial ones. The z-Arch has evolved very much in the last 10 years, compared to 360 and 370 days, and this makes code generation and the life of compiler builders much easier. [Nod] I believe that most of the above- as well as things like IEEE floating point support- is in late-model 390s and in the Hercules emulator. yes !! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....
Am 02.09.2013 10:37, schrieb Mark Morgan Lloyd: That's obviously far friendlier to a language like Pascal than the examples in most assembler-level treatises- I wonder how compatible it is with the description of the Linux ABI informally at http://linuxvm.org/present/SHARE99/S8139db.pdf ? Some remarks regarding code generation: if you have a language like C which doesn't support nested procedure definitions, it's perfectly simple. You can reach the local (auto) variables using register R13, and the parameters using R1. You only need another register to access the static data and some kind of heap management to support malloc() etc., and that's about all. With "classical" 360 machines, you had the problem that the offsets in the machine instructions only were 12 bits long, so you could only address 4 k from the position of a base register directly. That is, if your automatic data (of one procedure) was larger than 4 k, you were in trouble. Data after the 4 k barrier had to be addressed using two steps; first compute the address and the fetch the data - for example. With new z-Arch instructions, this is no problem any more. Same goes for the procedure code itself; PASCAL/VS (an old IBM compiler of the 1980 years) limited the size of procedures to 8 k - which is some hundred lines of source code. This, too, is no problem today any more, because, when you use the new relative branches, you don't need base registers for the code area. A language like Pascal, which allows the nesting of procedures and the access of auto variables that are defined outside the local procedure (that is: in procedures above the local procedure), you need to retrieve the stack frame of that procedure first. This is done by walking up the chain of the save areas and load the base address of the stack frame of the interesting procedure into another base register, different from R13 (for example). This is a problem, that a C compiler doesn't have - but it's well known to PL/1, too. This all is very well known and can be derived from the other compilers that deal with the z-Arch environment, for example the IBM commercial ones. The z-Arch has evolved very much in the last 10 years, compared to 360 and 370 days, and this makes code generation and the life of compiler builders much easier. Kind regards Bernd ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....
Am 01.09.2013 21:42, schrieb Mark Morgan Lloyd: No, I meant that Bernd suggested R1 earlier as a simulated stack pointer. Does IBM use R1 for this on variants of the architecture that have push/pop opcodes, or some other general-purpose register, or a dedicated register? R1 was only meant as an example. The true linkage and stack conventions of (most) IBM OSes are like this: R13 points to the save areas of the current procedure or function (that is the current stack frame of this procedure; at the beginning of this stack frame there is always a register save area for the 16 general purpose registers, which contain the return adress, entry point and parameter base adress, too). Following this save area, we have the local (automatic) variables of the current procedure or function. If a parameter list for the call of a subsequent procedure has to be built, this is also done in a work area which is part of the stack frame of this function, and before calling the next function, R1 is set to point to the beginning of this area. R15 always contains the entry point address for the new procedure, and R14 always contains the return address. All 16 registers are saved in the prologue of the new procedure and restored upon return - with the exception of R13 itself, which is handled separately - the save areas are chained together using the 2nd and 3rd word (backward and foreward pointer). This is the way how the contents of R13 are saved. The are machine instructions to do the register saves and restores in a convenient way - all the registers from R0 to R15 (with the exception of R13) are saved and restored using one machine instruction. It looks like this: STM R14,R12,12(R13) - that is, R14,R15, and R0 thru R12 are saved at offset 12 from R13. Kind regards Bernd ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....
Am 01.09.2013 20:30, schrieb Mark Morgan Lloyd: The problem here is that compiler design has moved on a lot since Wirth's day. It's not difficult to write a compiler using e.g. recursive descent or Meta-II which emits instructions for an abstract stack-based machine, and that might be a good match for a CPU with a small number of general-purpose registers. However it can be extremely difficult to optimise this for a modern CPU with a large register file, it's far more effective to give the frontend a rough idea of how many registers the backend has available to it and to warn it about known peculiarities. Agreed, but: you write: it's far more effective to give the frontend a rough idea ... the frontend? In my understanding the frontend of the compiler is the part that reads the source (scanner, parser) and generates a compact representation of the source - and different tables with identifiers, structure layouts etc. The commercial IBM compilers even have different frontends - one for PL/1, one for C - but when looking at the internals, it is the same compiler. The need to know about the properties of the target machine appears later, when it comes to code generation. This is in my opinion what the backend does ... but we will see ... I guess, the proper limit between frontend and backend and the correct definition will always be subject of discussions. Kind regards Bernd ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....
Am 01.09.2013 19:40, schrieb Mark Morgan Lloyd: At this point I'd throw in that one of the things the higher levels of the compiler knows is the overall properties of the registers, i.e. things like which ones are available for procedure parameters. This is one of the things that the lower level has to specify, so the lower-level units aren't there solely to do a macro-style substitution converting the compiler's internal representation to a sequence of assembler lines. The corollary of this is that it's fairly common for a new target CPU to necessitate higher-level changes, and these then have to be propagated to all of the other targets. Which is why it's important to keep people like Florian and Jonas happy :-) ok, so to keep Florian, Jonas and Sven (and others) happy, I would like to tell you that I am deeply impressed by the great work you all have done here. I appreciate that you discuss those things with me, and I'd like to discuss things a little further, because before investing time here, I would like to know as much as possible about the environment. The last few hours gave me much insight. Thank you for that. As I understand it now, we have several levels of the compiler: a) scanning and parsing the source code, which leads to a "tree representation" of the units, which IMO is a kind of in-storage-representation of the source code (and tables etc.), without much dependencies of the target, if any. I don't think, that informations about available registers etc. of the target machine are necessary at this level. b) the "tree representation" is translated into a "linear assembly list", which is target specific; from previous posts it sounds as if there are generic methods which help with this, and those methods of course need information about the target platform - but there is no "intermediate language" at this stage like in the P-Code case. (I know of other compilers, namely the IBM commercial ones, which translate in this stage for an abstract target machine which has an arbitrary number of registers, and the later "real" code generator puts it down to the real number, for example 16, and the missing registers are simulated in storage). This needs to be examined more. c) the "linear assembly list" is written to files, more or less without changes d) the files are assembled using an external assembler (in our case); it must be callable from the FPC compiler. There exists an interface for gas; interfaces to other assemblers have to be built. e) in the same way an external linker is used to link the units together. Is this correct so far? I'm not sure if and when I will find the time to jump really into this doing real work, but anyway: if we discuss these things now, it will remain in the archives of the mailing list and if others (like for example Paul Robinson) read this, they don't have to discuss it again. So IMO it's useful anyway. Thank you, kind regards Bernd ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....
Am 01.09.2013 18:01, schrieb Florian Klämpfl: Am 01.09.2013 16:55, schrieb Bernd Oppolzer: No need to answer to that ... I understood in the meantime that FPC does NOT rely on PUSH and POP instructions. Instead the linear assembler representation is already fully CPU specific. (which makes porting a bigger effort) Proof? It's my opinion. If the compiler translates the source language to machine code for an abstract target machine that is not too complicated (but well suited to the needs of the source language), you only have to translate the operations of this abstract machine one by one to your real target machine, which seems to me to be an easier task. Optimization can occur already in the stages, which are target-independent, but later, too. That's in my understanding Niklaus Wirth's P-Code approach. Furthermore, there is a file interface between the two stages, so that the first part of the compiler is very easy to port to new platforms. Only the second part has to be modified (in theory). My port of the McGill compiler (which is a descendent of Stanford, which is a descendent of the P4 compiler) works this way. In fact, I only ported it from one IBM opsys to another, so there was no problem at all. More interesting is, if I will succeed in porting it to an ASCII and Intel based platform (Windows, Linux, OS/2) and what sort of problems I will see when doing that. When I did some extensions to the compiler (new statement types like continue, break, return, which didn't exist before), I only had to change the first part of the compiler; the second one was not affected, because I didn't need new P-Code instructions. But maybe the same idea is present in FPC, too. I have to take a closer look at the tree representation of the FPC units after the first compile stage - when my time allows me to do so. I don't have a real feeling at the moment, if there is more work in the stage before that tree representation or after that - that is, if the tree representation looks more like the source code or already more like the linear assembly representation. Kind regards Bernd ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....
No need to answer to that ... I understood in the meantime that FPC does NOT rely on PUSH and POP instructions. Instead the linear assembler representation is already fully CPU specific. (which makes porting a bigger effort) Kind regards Bernd Am 01.09.2013 16:39, schrieb Bernd Oppolzer: Am 01.09.2013 16:02, schrieb Mark Morgan Lloyd: Bernd Oppolzer wrote: I'm about to head out, so have to be extremely brief. Thank you very much for that, that made things much clearer for me. So the compiler relies heavily on the external assembler and the syntax it supports, as long as you don't want to do changes to step 2 (that is, change the linear assembler representation, which IMO should not be done in the first step). And: the assembler is not called once, but for every unit. So here, I think, we have some problems or issues, because, as already pointed out, the z-Arch doesn't have PUSH and POP instructions, and I guess that the outcome of the linear assembler representation will not be very suitable to the things that the z-Arch instruction set provides, although in the meantime there are some 1500 instructions. Understanding that, I would now like to have some description of the linear assembler representation that FPC generates, that is: it is of course not target-specific, but it does of course do some assumptions on the type of the underlying hardware. Look at the output when using FPC's -a options, for example -aln... that might in practice need the EXTDEBUG setting during compilation but I can't go into more detail now. Push will typically be used to put parameters onto the stack, otherwise they'll be accessed by indexed operation. The stack frame is discarded by target-specific code. Thank you for that; I will take a look at it, although I have some doubts, if the output is "target-specific" or "not target-specific" - and if my understanding of the linear assembler representation being "not target-specific" is right. For that question I would like some statement from the core developers: how would you deal with a machine that has no built in PUSH instruction? For example if a function call puts five parameters on the stack, which is LD A PUSH LD B PUSH LD C PUSH LD D PUSH LD E PUSH CALL FUNC given an accumulator which is target of LD and a PUSH instruction which PUSHes the content of the accumulator to the stack. In my understanding this could be the not-target specific representation of the calling sequence The z-Arch could produce something like L R5,A AHI R1,4 ST R5,0(R1) L R5,B AHI R1,4 ST R5,0(R1) L R5,C AHI R1,4 ST R5,0(R1) L R5,D AHI R1,4 ST R5,0(R1) L R5,E AHI R1,4 ST R5,0(R1) here evere PUSH is emulated by the AHI (increment of the "stack pointer" R1) and then the indirect store. But more efficient would be: L R5,A ST R5,0(R1) L R5,B ST R5,4(R1) L R5,C ST R5,8(R1) L R5,D ST R5,12(R1) L R5,E ST R5,16(R1) AHI R1,20 still more efficient, if you use other registers (not only R5); if so, you can maybe store all the values into the stack using only one instruction (STM) - if the variables are loaded into consecutive registers (R5, R6, R7 and so on). That's what the existing compilers on z-Arch normally do - they don't compile the PUSH instructions one by one as in the first example, but in contrast, as there are no PUSH/POP instructions provided by the hardware, they do some efforts to do at least only one increment to the stack pointer (like outlined above) which is done in the procedure or function prologue. Now my question is: do you think that this is a major problem for a FPC port to z-Arch? Are my assumptions right so far? Should we start with an easy solution and check the performance implications later? Maybe there is a clever solution to that ... Kind regards Bernd ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....
Am 01.09.2013 16:12, schrieb Jonas Maebe: So my question is: is it possible to modify the outcome of step 2 (the linear assembler representation) depending on the target platform The linear assembler representation is already 100% platform-specific (as Sven mentioned above). FPC does not have a platform-independent internal RTL (register transfer language) representation. Thank you. So my assumptions so far were plain wrong. The difference between platforms is already in the stages above stage 2. That is (cited from Sven's mail): Also the compile process of FPC is roughly this: - for each used unit: - parse the unit and generate a node tree for each procedure/function/method (basically platform independant) - generate a CPU specific linear assembler representation of each node tree (this representation is independant of the specific assembler used) - if an external assembler (e.g. GNU as) is used: convert the assembler lists to assembler files - call the assembler (internal assemblers work on the assembler lists directly) to generate the object file - for external linkers (e.g. GNU ld): write a linkscript to instrument the external linker - call the linker (internal linkers work directly on the in memory information the compiler has gathered) only the first step - node tree - is platform independant, and the translations from there is already CPU specific - oh, I see, it's written there - I looked at the word "independant" in the paranthese - my fault ... Sorry for that ... Then the main effort is to understand what the contents of the node tree mean and to build another variant of step 2 (for z-Arch). Kind regards Bernd ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....
Am 01.09.2013 16:02, schrieb Mark Morgan Lloyd: Bernd Oppolzer wrote: I'm about to head out, so have to be extremely brief. Thank you very much for that, that made things much clearer for me. So the compiler relies heavily on the external assembler and the syntax it supports, as long as you don't want to do changes to step 2 (that is, change the linear assembler representation, which IMO should not be done in the first step). And: the assembler is not called once, but for every unit. So here, I think, we have some problems or issues, because, as already pointed out, the z-Arch doesn't have PUSH and POP instructions, and I guess that the outcome of the linear assembler representation will not be very suitable to the things that the z-Arch instruction set provides, although in the meantime there are some 1500 instructions. Understanding that, I would now like to have some description of the linear assembler representation that FPC generates, that is: it is of course not target-specific, but it does of course do some assumptions on the type of the underlying hardware. Look at the output when using FPC's -a options, for example -aln... that might in practice need the EXTDEBUG setting during compilation but I can't go into more detail now. Push will typically be used to put parameters onto the stack, otherwise they'll be accessed by indexed operation. The stack frame is discarded by target-specific code. Thank you for that; I will take a look at it, although I have some doubts, if the output is "target-specific" or "not target-specific" - and if my understanding of the linear assembler representation being "not target-specific" is right. For that question I would like some statement from the core developers: how would you deal with a machine that has no built in PUSH instruction? For example if a function call puts five parameters on the stack, which is LD A PUSH LD B PUSH LD C PUSH LD D PUSH LD E PUSH CALL FUNC given an accumulator which is target of LD and a PUSH instruction which PUSHes the content of the accumulator to the stack. In my understanding this could be the not-target specific representation of the calling sequence The z-Arch could produce something like L R5,A AHI R1,4 ST R5,0(R1) L R5,B AHI R1,4 ST R5,0(R1) L R5,C AHI R1,4 ST R5,0(R1) L R5,D AHI R1,4 ST R5,0(R1) L R5,E AHI R1,4 ST R5,0(R1) here evere PUSH is emulated by the AHI (increment of the "stack pointer" R1) and then the indirect store. But more efficient would be: L R5,A ST R5,0(R1) L R5,B ST R5,4(R1) L R5,C ST R5,8(R1) L R5,D ST R5,12(R1) L R5,E ST R5,16(R1) AHI R1,20 still more efficient, if you use other registers (not only R5); if so, you can maybe store all the values into the stack using only one instruction (STM) - if the variables are loaded into consecutive registers (R5, R6, R7 and so on). That's what the existing compilers on z-Arch normally do - they don't compile the PUSH instructions one by one as in the first example, but in contrast, as there are no PUSH/POP instructions provided by the hardware, they do some efforts to do at least only one increment to the stack pointer (like outlined above) which is done in the procedure or function prologue. Now my question is: do you think that this is a major problem for a FPC port to z-Arch? Are my assumptions right so far? Should we start with an easy solution and check the performance implications later? Maybe there is a clever solution to that ... Kind regards Bernd ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....
Am 01.09.2013 12:26, schrieb Sven Barth: If someone wants to port the compiler to a new target processor it is advisable to look whether there exists an OS that is already supported by FPC, because then "only" the code generator and the CPU specific parts of the RTL need to be implemented while the remaining RTL can be reused which simplifies the first steps of the port. Otherwise you'd need to implement the code generator and a more or less complete RTL. So as Linux seems to be available at least for some variants of the CPU I would strongly suggest to target Linux first and other OSes later. Also the compile process of FPC is roughly this: - for each used unit: - parse the unit and generate a node tree for each procedure/function/method (basically platform independant) - generate a CPU specific linear assembler representation of each node tree (this representation is independant of the specific assembler used) - if an external assembler (e.g. GNU as) is used: convert the assembler lists to assembler files - call the assembler (internal assemblers work on the assembler lists directly) to generate the object file - for external linkers (e.g. GNU ld): write a linkscript to instrument the external linker - call the linker (internal linkers work directly on the in memory information the compiler has gathered) Thank you very much for that, that made things much clearer for me. So the compiler relies heavily on the external assembler and the syntax it supports, as long as you don't want to do changes to step 2 (that is, change the linear assembler representation, which IMO should not be done in the first step). And: the assembler is not called once, but for every unit. So here, I think, we have some problems or issues, because, as already pointed out, the z-Arch doesn't have PUSH and POP instructions, and I guess that the outcome of the linear assembler representation will not be very suitable to the things that the z-Arch instruction set provides, although in the meantime there are some 1500 instructions. Understanding that, I would now like to have some description of the linear assembler representation that FPC generates, that is: it is of course not target-specific, but it does of course do some assumptions on the type of the underlying hardware. Maybe, for example, it assumes the existence of PUSH and POP instructions and some number of registers which can hold fixed point and floating point values and which are the target of the PUSH and POP instructions (and, of course, ASCII). The z-Arch Hardware, in contrast, normally does not access parameters - for example - by issuing individual PUSH or POP instructions, but - for example - if there are ten parameters requiring - say - 64 bytes of storage, it increments the "stack pointer" only once (by 64) and accesses the parameters by relative offsets to the value of the "stack pointer". Simulating the individual PUSHs and POPs by Assembler macros would by possible, but it would be a waste of time. So my question is: is it possible to modify the outcome of step 2 (the linear assembler representation) depending on the target platform - which is desirable in my opinion for performance reasons - or: should we stick with the outcome of step 2 - which contains probably PUSH and POP instructions in gas syntax etc - and simply try to convert them in the one or other way to z-Arch instructions - z Assembler Macros or a more intelligent assembler writer function which converts gas syntax to z Assembler syntax - and accept the performance degradation in the first place? BTW: is it possible to print the linear assembler representation - the outcome of step 2 - which in my understanding is NOT target-specific - and compare it - for example - to the assembler code generated for MIPS? I believe that from that mapping there could indeed be learned something ... For a new port it is advisable to not implement internal assemblers and linkers, because that means more work, but to use existing tools for the given platform. And here like for the RTL assembler/linker interfaces for the GNU assembler and linker already exist which simplify a port. Later on additional assembler/linker interfaces for other assemblers/linkers can be added or even an internal assembler and/or linker can be written. I, too, would try to rely on existing assemblers and linkers, but I have the feeling that HLASM (or free Assemblers supporting the z-Arch vocabulary) is a better choice than gas. I believe that there are some people out there waiting for FPC being available on z-Arch, and they are not all Unix-aware, but they read and understand the classical z-machinery well and would like it, if FPC was available there, without additional prerequisites (from their point of view). Of course, providing an internal assembler/linker is too much work and even not necessary, in my opinion. Regards, Sven _
Re: [fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....
Am 21.08.2013 22:17, schrieb Steve: Mark Morgan Lloyd wrote > Otherwise we also rely on external tools (mostly the GNU linker) > here. So as a first step you'd choose the approach of using an > external assembler and linker, because simply calling a third party > utility is easier than completely implementing an internal assembler > and linker. With the caveat here that as I understand it experienced IBM programmers avoid the GNU assembler like the plague, since it doesn't have anything like the sort of macro facilities they're used to. By implication, that would imply that they prefer to avoid the GNU linker and related tools as well. There is a problem inherent in this discussion; zArch is not one environment! It's one architecture supporting multiple operating systems, much like the 386/486/586/686 etc supports Linux or DOS or OS/2 or Windows (all 37 versions) etc. zArch has MVS (in all it's varieties) VM, DOS, LINUX, MFT, MVT, MUSIC/SP, and loads of other more niche stuff. In addition to all this, later versions of MVS supply a POSIX compliant shell called OMVS. GNU anything is available in hardly any of these environments even if we can handle the brain-dead assembler. This is correct, but it should be possible to cover most of those systems with one RTL - much the same way as LE (language environment) does it in the "big" IBM world, too. > Just to name a few: you'll need to get parameter passing for functions > correctly Which leads to another issue: the 370 is a register-based system without a stack as understood today. Parameters are mostly passed in registers, but this is largely hidden since supervisor calls etc. are usually hidden in macros. I am an MVS person so I can't speak for the other lot but parameter passing is mostly done in storage. The standard linkage conventions used allow for two 32-bit signed or unsigned integers (64-bit in later models). Anything else is passed in a storage area pointed to by register 1. Where this storage area comes from is complex and variable. My guess that the other IBM systems have similar models. A further guess is that Linux based code allocates an area of storage, points a register at it, write a couple of mickey mouse macros and bingo, a stack. Ok. So what? This makes parameter passing just easier, because you don't have to deal with special cases for - say - low number of parameters. It's all the same method. And Pascal has call by value and call by reference and - for example - not the strange descriptor and dope vector things that PL/1 has. The stack is simulated by simply incrementing and decrementing the stack pointer on procedure entry and return and addressing relatively to it. At least that is what is done in the "classical" compilers. I recently learned a bit about the MIPS architecture, and it seemed to me to have some similarities to IBM's, so I guess, a kind of "translation" from MIPS to IBM could be successful. Many people say that the IBM platform is the only remaining platform today that reasonably can be programmed using assembly language, because of the clear structure of the instruction set. My own feeling is that it would be best to start targeting a late-model 390, which does have a stack etc., and to use the standard GNU assembler and linker (as and ld)/initially/ targeting Linux. Any other combination (i.e. a proprietary assembler etc. with an antique MVS as target) is going to cause nothing but grief, since it makes it very difficult for developers skilled with FPC but not with IBM mainframes to give any practical help. Late-model 390's have a stack, but not as you know it. It's not something you can go around lobbing arbitrary data at. It is reserved for data saved during subroutine linkage using the appropriate hardware instruction (Branch and Stack). This includes various register sets, PSW status info etc) and an additional two 32-bit signed or unsigned integers (64-bit in later models). Steve I would strongly suggest not to use the "new" hardware stack, but instead to rely on the OS linkage conventions (save area chaining, register 13), which in fact are used by most of the operating systems mentioned above - with minor differences. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....
Am 20.08.2013 16:54, schrieb Mark Morgan Lloyd: > Just to name a few: you'll need to get parameter passing for functions > correctly Which leads to another issue: the 370 is a register-based system without a stack as understood today. Parameters are mostly passed in registers, but this is largely hidden since supervisor calls etc. are usually hidden in macros. My own feeling is that it would be best to start targeting a late-model 390, which does have a stack etc., and to use the standard GNU assembler and linker (as and ld) /initially/ targeting Linux. Any other combination (i.e. a proprietary assembler etc. with an antique MVS as target) is going to cause nothing but grief, since it makes it very difficult for developers skilled with FPC but not with IBM mainframes to give any practical help. Sorry, I don't follow some of the comments in this thread. First, what is a stack? A stack IMO consists of a stack pointer provided by the hardware, that is, a register. And even the old IBM machines have many registers that can be seen as stack pointers; you only have to select one. That is in fact the way that the stack has been implemented in "old" compilers on "old" IBM hardware, be it Fortran, Pascal, PL/1 or C. All those languages needed kind of stacks for local variables of procedures etc. So IMO there is no need to target new hardware; this will be very expensive and excludes the use of Hercules simulators and free versions of IBM operating systems for first tests. Even todays IBM compilers don't use the "new" hardware stack. And then: I have some doubts about the linkage between FPC and the GNU tools, like as and ld. Why is it easier to port FPC to a Linux based system? If the compiler translates into an abstract intermediate language first and then into an abstract assembly language maybe - for an abstract machine like the P-machine - then the nature of the assembler and linker used should be irrelevant. Maybe there is some misunderstanding on my - or our - part; I have the Wirth compilers in mind, and there is a clear separation between the machine independent parts - phase 1 - which generates P-code and the machine dependent parts - phase 2 and runtime. Even if there is no such separation in FPC, it should IMO be possible to develop and test the code generation separately. I, too, had the difficulties, like Paul Robinson, that I did not get the cross-compiler working. My goal was, for example, to have a cross compiler running on Windows, that produces Assembler output for MIPS for example, and for a second target S370, which is at the beginning simply a copy of MIPS, producing the identical output, but then I could make changes to the S370 code generation and try to get the results running on a simulated or real 370 hardware. Could you maybe outline the steps that are necessary to create such an environment? Kind regards Bernd ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Porting FPC to IBM zArch
Am 17.08.2013 21:31, schrieb Mark Morgan Lloyd: Bernd Oppolzer wrote: - 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. 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 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Porting FPC to IBM zArch
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 Am 24.07.2013 14:19, schrieb Sven Barth: Am 24.07.2013 14:12, schrieb Bernd Oppolzer: 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? 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- Bernd Oppolzer --- *Oppolzer-Informatik * Dipl. Inf. Bernd Oppolzer Bärenhofstraße 23 70771 Leinfelden-Echterdingen --- Tel.: +49 711 2272522 priv.: +49 711 7949590 eMail: bernd.oppol...@t-online.de <mailto:bernd.oppol...@t-online.de>
Re: [fpc-devel] Porting FPC to IBM zArch
no problem at all :-) Am 24.07.2013 14:43, schrieb Mark Morgan Lloyd: Sven Barth wrote: We're heading off topic, no disrespect to Bernd intended. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Porting FPC to IBM zArch
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 Am 24.07.2013 11:46, schrieb Sven Barth: Am 24.07.2013 03:41, schrieb Bernd Oppolzer: - 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Porting FPC to IBM zArch
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 Am 24.07.2013 12:37, schrieb Mark Morgan Lloyd: Jonas Maebe wrote: On 24 Jul 2013, at 03:41, Bernd Oppolzer wrote: - 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Porting FPC to IBM zArch
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-2013PAGE 1
1 ) program DECOD ( INPUT , OUTPUT ) ;
2 ) (*$N+*)
3 ) var I : INTEGER ;
4356D 1) C1 : CHAR ;
5357D 1) C2 : CHAR ;
6358D 1) CH : CHAR ;
7359D 1) HEX : packed array [ 0 .. 15 ] of CHAR ;
8375D 1)
9375D 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
Am 24.07.2013 11:39, schrieb Sven Barth:
Am 24.07.2013 10:02, schrieb Jonas Maebe:
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Porting FPC to IBM zArch
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
Am 24.07.2013 10:02, schrieb Jonas Maebe:
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?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Porting FPC to IBM zArch
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
Am 24.07.2013 10:02, schrieb Jonas Maebe:
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.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Porting FPC to IBM zArch
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
