Re: [fpc-devel] On a port of Free Pascal to the IBM 370
AFAI learned: I suppose the code generator should be doable, regarding that there already are several supported CPUs. At least a working compiler might come into existence in a decent amount of time, adding optimizations is another project. OTOH I suppose that a porting the RTL to a mainframe OS will not be easy and without this the compiler is quite useless. Is there a Java virtual machine for zSystem ? Maybe using the currently evolving FPC for Java target might be another way to go. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On Wed, 18 Jan 2012, Michael Schnell wrote: AFAI learned: I suppose the code generator should be doable, regarding that there already are several supported CPUs. At least a working compiler might come into existence in a decent amount of time, adding optimizations is another project. OTOH I suppose that a porting the RTL to a mainframe OS will not be easy and without this the compiler is quite useless. I do not think it is more difficult than any other OS. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
michael.vancann...@wisa.be wrote: On Wed, 18 Jan 2012, Michael Schnell wrote: AFAI learned: I suppose the code generator should be doable, regarding that there already are several supported CPUs. At least a working compiler might come into existence in a decent amount of time, adding optimizations is another project. OTOH I suppose that a porting the RTL to a mainframe OS will not be easy and without this the compiler is quite useless. I do not think it is more difficult than any other OS. I've got reservations because of the EBCDIC issue. My own opinion is that this effort would be far better targeting Linux on a comparatively recent model of machine, since these are well-supported by the Hercules emulator which gives developers an absolutely standard working environment: which is, obviously, why I wrote it up a few months ago. I'm sure Paul has his reasons that we all need to respect, but I don't think that using a 370 emulator (i.e. at least two architectures out of date) plus an obsolete operating system is the place to start. I admit to having considered this as a long-term project, but what I don't have is a good understanding of the architecture's assembler-level programming. However I think I need to make the general point here that IBM Assembler is understood in the industry to encompass that which is needed to write application-level programs in CISC assembler (plus macro support etc.), and that even somebody skilled in that particular black art might need to enter unfamiliar territory when it comes to the operations required by a compiler's code generation (e.g. commercial programming doesn't do large amounts of stack-relative addressing). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On Wed, January 18, 2012 10:15, michael.vancann...@wisa.be wrote: On Wed, 18 Jan 2012, Michael Schnell wrote: AFAI learned: I suppose the code generator should be doable, regarding that there already are several supported CPUs. At least a working compiler might come into existence in a decent amount of time, adding optimizations is another project. OTOH I suppose that a porting the RTL to a mainframe OS will not be easy and without this the compiler is quite useless. I do not think it is more difficult than any other OS. ...except for the EBCDIC stuff, because the common parts of our RTL assume ASCII in many places (most of them probably not that difficult to fix by adding some platform specific constants changing the behaviour from ASCII only to consider EBCDIC too, but scattered around many places and thus difficult to find). That doesn't mean it shouldn't be doable, of course, it will just require debugging even parts which didn't have to be touched during ports to other operating systems. Still, starting with the Linux for S/390 (or are S/390 and S/370 completely different animals?) as suggested by Mark would be probably a very good idea to avoid having to tackle both a different HW platform and a different OS at the same time (the Linux port to S/390 apparently uses ASCII according to what I found on Internet). Obviously, the OS may follow once the new HW platform is in working state. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On 01/18/2012 10:51 AM, Tomas Hajny wrote: Still, starting with the Linux for S/390... A nice thing being that - AFAI read - the more recent versions of the OS allow for starting multiple virtualized Linux instances. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On Wed, 18 Jan 2012, Tomas Hajny wrote: On Wed, January 18, 2012 10:15, michael.vancann...@wisa.be wrote: On Wed, 18 Jan 2012, Michael Schnell wrote: AFAI learned: I suppose the code generator should be doable, regarding that there already are several supported CPUs. At least a working compiler might come into existence in a decent amount of time, adding optimizations is another project. OTOH I suppose that a porting the RTL to a mainframe OS will not be easy and without this the compiler is quite useless. I do not think it is more difficult than any other OS. ...except for the EBCDIC stuff, because the common parts of our RTL assume ASCII in many places (most of them probably not that difficult to fix by adding some platform specific constants changing the behaviour from ASCII only to consider EBCDIC too, but scattered around many places and thus difficult to find). That doesn't mean it shouldn't be doable, of course, it will just require debugging even parts which didn't have to be touched during ports to other operating systems. ? It just means you must convert ascii to ebcdic in OS calls that require strings. All these calls must be re-implemented anyway, so a generic routine to do this conversion seems like the obvious path. I doubt this will be the real bottleneck :-) As for using Linux: I have no idea how this works in practice, so I can't comment on that. I know that people here use Hercules inside linux to develop for zSeries, but then again running a linux inside that seems a bit like overkill :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
Tomas Hajny wrote: ...except for the EBCDIC stuff, because the common parts of our RTL assume ASCII in many places (most of them probably not that difficult to fix by adding some platform specific constants changing the behaviour from ASCII only to consider EBCDIC too, but scattered around many places and thus difficult to find). That doesn't mean it shouldn't be doable, of course, it will just require debugging even parts which didn't have to be touched during ports to other operating systems. I used a macro processor called Stage2 for years which was completely character-set agnostic, assuming only that 1..9 were contiguous and in sequence and putting them (plus a small number of other special characters) on the first line of any file; I was looking at an APL implementation a few weeks ago which did something similar. Thirty years ago it might have been worth writing an RTL like that, but these days ASCII and UTF-8 are so utterly dominant that I see little point. Still, starting with the Linux for S/390 (or are S/390 and S/370 completely different animals?) as suggested by Mark would be probably a The S/390 is an incremental change from the S/370, in the same way that zSeries is an incremental change from S/390. However in any one of those architectures there is a significant number of models, and- crucially- there is a change at one model of the 390 which allows it to accept inline literals rather than insisting that these be in a table which is within 4K of the current PC. As I understand it, GCC doesn't support models that predate that change, and frankly I don't see why FPC should either; however I don't know the model's formal designation or how to check for it in RTL code. very good idea to avoid having to tackle both a different HW platform and a different OS at the same time (the Linux port to S/390 apparently uses ASCII according to what I found on Internet). Obviously, the OS may follow once the new HW platform is in working state. In my experience, Linux running on an (emulated) S/390 looks almost exactly like Linux running on any other CPU. There are no character set issues, and no obvious issues relating to endianness or floating-point format (I've had no need to examine FP binary representation, but I think that these days the machines support IEEE). I'd also point out that IBM have a developer relations program, which makes a (Red Hat?) VM available to anybody who needs it. I'm sure this project would qualify for that. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
michael.vancann...@wisa.be wrote: As for using Linux: I have no idea how this works in practice, so I can't comment on that. I know that people here use Hercules inside linux to develop for zSeries, but then again running a linux inside that seems a bit like overkill :-) It's trivial and performs well. See the timing figures I put up at http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators#Relative_Performance -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
Am 17.01.2012 21:52, schrieb Paul Robinson: From: Paul Robinsonp...@paul-robinson.us As has probably been a bit of a scare to some people, I've more-or-less unofficially announced by putting up an article on the Free Pascal Wiki regarding how I've decided I am going to work on porting the Free Pascal compiler to the IBM 370 series mainframe, otherwise known as the zSeries. And that, having spoken to a few people here, I've been made aware this has sort of been scary or incredible to some of the other people working on this project because they realize that there is a hell of a lot of work involved and I may not be aware of what I'm up against. I can understand, and I can sympathize with their thoughts. It's not that I'm scared that you want to tackle this it's more that I've seen that you based your How-To on assumptions that are wrong or at least not good and wanted to help you in this regard. I am aware, first, that this will be a huge undertaking; this is not a weekend project. I'm probably looking at a minimum six months work, possibly longer. I have not yet started a new CPU target myself (only an OS target), but I can imagine that you're not that far off with the time needed... So anyway, I know there's a lot involved, there will be fits, and starts, and things won't always go right. But it's a learning experience, and, if you follow this as it goes along over the months as it progresses, maybe you'll learn something too. Well, then let's get started with bringing you on track: 1. You wrote that you use the source code of FPC 2.6.0 and copied the compiler and rtl directories to some other workplace. I suggest you to use a SVN checkout of the development version (you can find the links here: http://www.freepascal.org/develop.var (at Connect to Source Repository with SVN)), because than you can more easily revert back something. Also there were quite a few changes from 2.6.0 to 2.7.1 and thus it's better to work with the most recent source. 2. I suggest you to use the Lazarus IDE to do compiler development (you might use the text mode IDE (fp) as well, but I myself only use Lazarus for that). You can then copy one of the project files (*.lpi) in the compiler directory (e.g. ppi386.lpi) and paste it as ppi370.lpi. You can then open this project in Lazarus and adjust the defines (in tab Other replace -dI386 with -dI370) and output directory (exchange i386/units with i370/units) in the project settings. Afterwards you should be able to compile the compiler using (Ctrl+)F9 (ok, you won't at first, because you yet need to adjust the source for i370) 3. I noticed that you wanted to add a unit i_i370 to the compiler unit and to the directory systems. This is wrong. The units listed in the compiler unit are the target operating systems (e.g. Windows, Linux, DOS), not the underlying architecture. Thus you'd only add a i_osvs1 (if I remember the name correctly) to that unit and directory, but you don't need to do this know as you first need to implement the architecture support. This architecture support is located in the corresponding CPU unit (e.g. ARM, PowerPC, i386, x86_64 (the latter two share the x86 directory as well)) and is included by using the cputarg in the unit compiler. This unit is located in the corresponding CPU directory. Thus I'd suggest you to copy the directory of an architecture (e.g. MIPS as this is a smaller and younger one) and name that i370 (now the unit output path I mentioned in 2 will make sense ;) ). 4. I read in your How-To that you stumpled upon units like sysutils and stubbed them. You don't need to care about these yet. These are only needed if you compile programs for the target platform which use that units. The only unit you might want to stub at the beginning is the System unit which is located in $fpcdir/rtl/$target/system.pp (where $fpcdir is your source directory and $target is one of the supported targets (e.g. linux, win32, etc.)). The most important part you'll need there is a function or procedure (depending on the operating system) which will contain your real entry point (the begin...end. in a program file is NOT the real entry point, this part is called PASCALMAIN and is called from within the real entry point). So at the beginning you can mostly concentrate on your i370 directory with adding some types here and there (like the assemblertype that you already added). I myself can't help with porting FPC to a new architecture, as I haven't done that yet (only to a new operating system target). But AFAIK Mark Morgan Lloyd worked on the MIPS target and of course there are compiler developers who implemented new architectures. Regarding general compiler questions and those regarding the implementation of a new OS target I might be able to help you, so just mail to the list and I'll try to see what I can do. BTW: It might indeed be the best - as suggested by others already - to
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On Wed, January 18, 2012 11:23, michael.vancann...@wisa.be wrote:
On Wed, 18 Jan 2012, Tomas Hajny wrote:
On Wed, January 18, 2012 10:15, michael.vancann...@wisa.be wrote:
On Wed, 18 Jan 2012, Michael Schnell wrote:
AFAI learned:
I suppose the code generator should be doable, regarding that there
already
are several supported CPUs. At least a working compiler might come
into
existence in a decent amount of time, adding optimizations is another
project.
OTOH I suppose that a porting the RTL to a mainframe OS will not be
easy
and
without this the compiler is quite useless.
I do not think it is more difficult than any other OS.
...except for the EBCDIC stuff, because the common parts of our RTL
assume
ASCII in many places (most of them probably not that difficult to fix by
adding some platform specific constants changing the behaviour from
ASCII
only to consider EBCDIC too, but scattered around many places and thus
difficult to find). That doesn't mean it shouldn't be doable, of course,
it will just require debugging even parts which didn't have to be
touched
during ports to other operating systems.
? It just means you must convert ascii to ebcdic in OS calls that require
strings. All these calls must be re-implemented anyway, so a generic
routine
to do this conversion seems like the obvious path. I doubt this will be
the
real bottleneck :-)
It should not be a bottleneck, but I'm afraid that you underestimate it a
bit. As an example, searching for #10 and #9 across files (just) in
rtl/inc (there's much more in rtl/objpas) shows quite a few places which
would need to be changed for EBCDIC support and which are not touched
otherwise during a RTL port (control characters have completely different
layout in EBCDIC compared to ASCII). Also case insensitive search for
'a' (just as an example - there are more ways how this can appear in the
code) finds several places containing code assuming either certain
position of the standard alphabet ('a'..'z') in the character set - both
assumptions regarding the absolute value of 'a' (or 'A') used e.g. for
translation of hexadecimal numbers, or assumptions about the whole
alphabet being in one consecutive range (which is not the case for
EBCDIC).
As for using Linux: I have no idea how this works in practice, so I can't
comment on that. I know that people here use Hercules inside linux to
develop for zSeries, but then again running a linux inside that seems a
bit
like overkill :-)
Sorry, I don't understand this comment (probably because I know nothing
about Hercules). My point was simply that Linux port to S/390 exists so
one could start by creating support for the S/390 platform and testing
this new platform support with the existing Linux RTL first before
continuing with the RTL for zSeries (including necessary adaptations of
the common parts of our standard RTL).
Tomas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
michael.vancann...@wisa.be wrote: ? It just means you must convert ascii to ebcdic in OS calls that require strings. All these calls must be re-implemented anyway, so a generic routine to do this conversion seems like the obvious path. I doubt this will be the real bottleneck :-) Would you like to bet on that? What if it also meant that all the sources had to be rendered unto EBCDIC, and digraphs defined for characters that don't exist such as ^[] -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On Wed, 18 Jan 2012, Tomas Hajny wrote:
On Wed, January 18, 2012 11:23, michael.vancann...@wisa.be wrote:
On Wed, 18 Jan 2012, Tomas Hajny wrote:
On Wed, January 18, 2012 10:15, michael.vancann...@wisa.be wrote:
On Wed, 18 Jan 2012, Michael Schnell wrote:
AFAI learned:
I suppose the code generator should be doable, regarding that there
already
are several supported CPUs. At least a working compiler might come
into
existence in a decent amount of time, adding optimizations is another
project.
OTOH I suppose that a porting the RTL to a mainframe OS will not be
easy
and
without this the compiler is quite useless.
I do not think it is more difficult than any other OS.
...except for the EBCDIC stuff, because the common parts of our RTL
assume
ASCII in many places (most of them probably not that difficult to fix by
adding some platform specific constants changing the behaviour from
ASCII
only to consider EBCDIC too, but scattered around many places and thus
difficult to find). That doesn't mean it shouldn't be doable, of course,
it will just require debugging even parts which didn't have to be
touched
during ports to other operating systems.
? It just means you must convert ascii to ebcdic in OS calls that require
strings. All these calls must be re-implemented anyway, so a generic
routine
to do this conversion seems like the obvious path. I doubt this will be
the
real bottleneck :-)
It should not be a bottleneck, but I'm afraid that you underestimate it a
bit. As an example, searching for #10 and #9 across files (just) in
rtl/inc (there's much more in rtl/objpas) shows quite a few places which
would need to be changed for EBCDIC support and which are not touched
otherwise during a RTL port (control characters have completely different
layout in EBCDIC compared to ASCII). Also case insensitive search for
'a' (just as an example - there are more ways how this can appear in the
code) finds several places containing code assuming either certain
position of the standard alphabet ('a'..'z') in the character set - both
assumptions regarding the absolute value of 'a' (or 'A') used e.g. for
translation of hexadecimal numbers, or assumptions about the whole
alphabet being in one consecutive range (which is not the case for
EBCDIC).
But then you are assuming the RTL should be using EBCDIC internally as well ?
Obviously, that will be a lot more work.
But I don't think this should be so.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
Sven Barth wrote: You wrote that you use the source code of FPC 2.6.0 and copied the compiler and rtl directories to some other workplace. I suggest you to use a SVN checkout of the development version (you can find the links here: http://www.freepascal.org/develop.var (at Connect to Source Repository with SVN)), because than you can more easily revert back something. Also there were quite a few changes from 2.6.0 to 2.7.1 and thus it's better to work with the most recent source. Also there are things in trunk that aren't in released versions, for example when I started looking at MIPS I didn't appreciate that somebody (Florian?) had already backported much of David Zhang's (?) implementation. I suggest you to use the Lazarus IDE to do compiler development (you might use the text mode IDE (fp) as well, but I myself only use Lazarus for that). You can then copy one of the project files (*.lpi) in the compiler directory (e.g. ppi386.lpi) and paste it as ppi370.lpi. You can then open this project in Lazarus and adjust the defines (in tab Other replace -dI386 with -dI370) and output directory (exchange i386/units with i370/units) in the project settings. Afterwards you should be able to compile the compiler using (Ctrl+)F9 (ok, you won't at first, because you yet need to adjust the source for i370) I definitely found Lazarus indispensable once I started stepping through part-working code to find out where it was going wrong, I was able to run MIPS and PPC side-by-side on a PC. I noticed that you wanted to add a unit i_i370 to the compiler unit and to the directory systems. This is wrong. The units listed in the compiler unit are the target operating systems (e.g. Windows, Linux, DOS), not the underlying architecture. Thus you'd only add a i_osvs1 (if I remember the name correctly) to that unit and directory, but you don't need to do this know as you first need to implement the architecture support. This architecture support is located in the corresponding CPU unit (e.g. ARM, PowerPC, i386, x86_64 (the latter two share the x86 directory as well)) and is included by using the cputarg in the unit compiler. This unit is located in the corresponding CPU directory. Thus I'd suggest you to copy the directory of an architecture (e.g. MIPS as this is a smaller and younger one) and name that i370 (now the unit output path I mentioned in 2 will make sense ;) ). Perhaps now would be a good time for a core developer to add appropriate definitions to trunk, so that anybody working on the IBM port only needs to modify files in a directory off ./compiler. MIPS is OK, but there are some defines etc. that need to be sorted out. I've done a bit of work on this but I think it needs somebody with more experience to sort out my fixes and commit them. I myself can't help with porting FPC to a new architecture, as I haven't done that yet (only to a new operating system target). But AFAIK Mark Morgan Lloyd worked on the MIPS target and of course there are compiler developers who implemented new architectures. Bearing in mind that what I was looking at was code that had already been working in version 1 of the compiler, which had been massaged into some sort of shape for v2. I can claim very little credit, it was entirely grunt work. More relevant might be Jonas's recent work targeting the JVM, but I suspect that the classic IBM mainframe architecture is probably nearer MIPS or 68K than to JVM or a modern RISC. Historical note: I worked for a mainframe manufacturer in the early 80s after getting my first degree, so while I'm not intimate with the S/360...zSeries range I think I've got a bit of relevant experience. The important thing to appreciate is that at least some mainframe applications were written in assembler up until the late 70s, so IBM Assembler or Burroughs Medium System Assembler maps fairly trivially on a line-by-line basis to high-level languages such as COBOL. I think that about the last system designed to look like that was the VAX, even CISC microprocessors have a far more primitive repertoire of operations and data types. HEARTFELT PLEA: If Paul (or anybody else) starts making significant progress on this, I think that the community very badly needs a blow-by-blow account for future reference. Paul's notes in the wiki are very much to be applauded. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On Wed, January 18, 2012 11:57, michael.vancann...@wisa.be wrote:
On Wed, 18 Jan 2012, Tomas Hajny wrote:
On Wed, January 18, 2012 11:23, michael.vancann...@wisa.be wrote:
On Wed, 18 Jan 2012, Tomas Hajny wrote:
On Wed, January 18, 2012 10:15, michael.vancann...@wisa.be wrote:
On Wed, 18 Jan 2012, Michael Schnell wrote:
AFAI learned:
I suppose the code generator should be doable, regarding that there
already
are several supported CPUs. At least a working compiler might come
into
existence in a decent amount of time, adding optimizations is
another
project.
OTOH I suppose that a porting the RTL to a mainframe OS will not be
easy
and
without this the compiler is quite useless.
I do not think it is more difficult than any other OS.
...except for the EBCDIC stuff, because the common parts of our RTL
assume
ASCII in many places (most of them probably not that difficult to fix
by
adding some platform specific constants changing the behaviour from
ASCII
only to consider EBCDIC too, but scattered around many places and thus
difficult to find). That doesn't mean it shouldn't be doable, of
course,
it will just require debugging even parts which didn't have to be
touched
during ports to other operating systems.
? It just means you must convert ascii to ebcdic in OS calls that
require
strings. All these calls must be re-implemented anyway, so a generic
routine
to do this conversion seems like the obvious path. I doubt this will be
the
real bottleneck :-)
It should not be a bottleneck, but I'm afraid that you underestimate it
a
bit. As an example, searching for #10 and #9 across files (just) in
rtl/inc (there's much more in rtl/objpas) shows quite a few places which
would need to be changed for EBCDIC support and which are not touched
otherwise during a RTL port (control characters have completely
different
layout in EBCDIC compared to ASCII). Also case insensitive search for
'a' (just as an example - there are more ways how this can appear in
the
code) finds several places containing code assuming either certain
position of the standard alphabet ('a'..'z') in the character set - both
assumptions regarding the absolute value of 'a' (or 'A') used e.g. for
translation of hexadecimal numbers, or assumptions about the whole
alphabet being in one consecutive range (which is not the case for
EBCDIC).
But then you are assuming the RTL should be using EBCDIC internally as
well ?
Obviously, that will be a lot more work.
But I don't think this should be so.
I may be overlooking something, of course. However: Our RTL is based on
common (target specific) routines for reading (and writing) text and
binary files (do_read do_write). You cannot translate between ASCII and
EBCDID in these target specific routines because you don't know how the
input would be used at that point (not even mentioning the fact that there
is nothing like translation between ASCII and EBCDIC because there are
multiple different character sets for both and real conversion isn't
possible without taking this into account and knowing the real character
sets which again depends on the context which is again not known at this
low level). Unless I'm mistaken, this implies that you indeed need to
consider the (basic) EBCDIC layout as an alternative to the (basic) ASCII
layout directly within the RTL. This should be obviously done in a way not
impacting the RTL behaviour for other targets. However, that is certainly
possible using either constants differentiating between ASCII and EBCDIC
(thanks to elimination of the unused code identified at compile time by
the compiler), or using IFDEFs, or using special versions for certain
routines (located in different include files, etc.) - although I
personally believe that the last one is the least viable one in this case
due to likely duplication of majority of the code within such routines in
the two implementations.
Not even mentioning the additional minor issue with certain characters
(critical for Pascal source codes) not necessarily directly available in
_some_ (!) EBCDIC character sets as pointed out by Mark - again something
which cannot be handled in the general I/O routines because it only
becomes important when interpreting a general text as Pascal source code
(in this case, special support on the compiler side will be probably
necessary, i.e. this should have no impact to RTL, but it will again have
impact to the common parts of the compiler, namely scanner, not to target
specific units).
Tomas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Access violation during compilation
Hello everyone. I am trying to port a set of Delphi libraries to FPC and during compilation from the Lazarus IDE I get a Compilation aborted without any other explanation. Doing the build from a command prompt I get this: Compiling unit1.pas Compiling C:\Projects\MkCtrls\PropStorage.pas Compiling C:\Projects\MkCtrls\UHom.pas Compiling C:\Projects\MkCtrls\uHomXPath.pas Fatal: Compilation aborted An unhandled exception occurred at $000100042D3C: EAccessViolation: Access violation $000100042D3C $000100120431 $00010011EC8B $000100121075 $00010012109C $00010012109C $00010012109C $000100121DFB $00010010CC45 $000100109CF8 $00010010C68B $00010010CC75 $000100107BF4 $000100107A39 $00010003D596 $00010014759E $0001001520A1 It seems that the compiler itself throws an AV. I am trying to isolate the code structure that causes this AV so that I can rewrite it or report a bug but I haven't been able to do it so far because the involved units are quite complex and depend on each other and other units heavily. Is there any way to get the compiler to give me more information about what causes the AV? I am using fpc 2.7.1 for OS Win64 and CPU x86/64 but I get the same result with Win32/i386. ΤΙΑ. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] small patch for imagemagic
Hi patch for http://svn.freepascal.org/svn/fpc/trunk/packages/imagemagick Small fix for build in Delphi -- Don`t drink and drive, smoke and fly! 12.patch Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
Sven Barth schrieb: 1. You wrote that you use the source code of FPC 2.6.0 and copied the compiler and rtl directories to some other workplace. I suggest you to use a SVN checkout of the development version (you can find the links here: http://www.freepascal.org/develop.var (at Connect to Source Repository with SVN)), because than you can more easily revert back something. Also there were quite a few changes from 2.6.0 to 2.7.1 and thus it's better to work with the most recent source. I wouldn't suggest to use 2.7 (trunk) as the development base, with Unicode and other features under development. Once a machine and RTL has been implemented for 2.6, it should not be so hard to merge it into trunk. I also would suggest git for all experiments, with better branch, merge and revert capabilites than SVN offers. 2. I suggest you to use the Lazarus IDE to do compiler development +1 DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] small patch for imagemagic
On 18 Jan 2012, at 13:01, Alexey Voychehovich wrote:
patch for http://svn.freepascal.org/svn/fpc/trunk/packages/imagemagick
Small fix for build in Delphi
You can use {$z4}, that works both in FPC and in Delphi.
Jonas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
Tomas Hajny wrote:
is nothing like translation between ASCII and EBCDIC because there are
multiple different character sets for both and real conversion isn't
possible without taking this into account and knowing the real character
sets which again depends on the context which is again not known at this
low level). Unless I'm mistaken, this implies that you indeed need to
consider the (basic) EBCDIC layout as an alternative to the (basic) ASCII
If the RTL were fully Unicode-aware then possibly this could be handled
by host localisation, presumably on a classic IBM OS the JCL will state
unambiguously which variant of EBCDIC is expected.
I think we need to wait for some input from Paul on this one, after all
he's the project's instigator.
Not even mentioning the additional minor issue with certain characters
(critical for Pascal source codes) not necessarily directly available in
_some_ (!) EBCDIC character sets as pointed out by Mark - again something
which cannot be handled in the general I/O routines because it only
becomes important when interpreting a general text as Pascal source code
(in this case, special support on the compiler side will be probably
necessary, i.e. this should have no impact to RTL, but it will again have
impact to the common parts of the compiler, namely scanner, not to target
specific units).
I can't remember the source, but my understanding is that Wirth
originally worked with an IBM 029 keypunch, possibly connected preparing
decks for a CDC. He specifically defined (* and *) as digraphs for { and
}, and I think there were others including (. and .) for [ and ] Did FPC
/ever/ fully-support these?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] small patch for imagemagic
you are change the code? or me send patch again?
On Wed, Jan 18, 2012 at 2:10 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On 18 Jan 2012, at 13:01, Alexey Voychehovich wrote:
patch for http://svn.freepascal.org/svn/fpc/trunk/packages/imagemagick
Small fix for build in Delphi
You can use {$z4}, that works both in FPC and in Delphi.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
--
Don`t drink and drive, smoke and fly!
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] small patch for imagemagic
On 18 Jan 2012, at 13:16, Alexey Voychehovich wrote: you are change the code? or me send patch again? It's best to submit patches via http://bugs.freepascal.org/set_project.php?project_id=6 , then they can't be forgotten. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] small patch for imagemagic
http://bugs.freepascal.org/view.php?id=2 like this? On Wed, Jan 18, 2012 at 2:24 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 18 Jan 2012, at 13:16, Alexey Voychehovich wrote: you are change the code? or me send patch again? It's best to submit patches via http://bugs.freepascal.org/set_project.php?project_id=6 , then they can't be forgotten. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- Don`t drink and drive, smoke and fly! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] small patch for imagemagic
On 18 Jan 2012, at 13:32, Alexey Voychehovich wrote: http://bugs.freepascal.org/view.php?id=2 like this? Yes, thanks. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On Wed, January 18, 2012 13:14, Mark Morgan Lloyd wrote:
Tomas Hajny wrote:
is nothing like translation between ASCII and EBCDIC because there are
multiple different character sets for both and real conversion isn't
possible without taking this into account and knowing the real character
sets which again depends on the context which is again not known at this
low level). Unless I'm mistaken, this implies that you indeed need to
consider the (basic) EBCDIC layout as an alternative to the (basic)
ASCII
If the RTL were fully Unicode-aware then possibly this could be handled
by host localisation, presumably on a classic IBM OS the JCL will state
unambiguously which variant of EBCDIC is expected.
I think we need to wait for some input from Paul on this one, after all
he's the project's instigator.
Not even mentioning the additional minor issue with certain characters
(critical for Pascal source codes) not necessarily directly available in
_some_ (!) EBCDIC character sets as pointed out by Mark - again
something
which cannot be handled in the general I/O routines because it only
becomes important when interpreting a general text as Pascal source code
(in this case, special support on the compiler side will be probably
necessary, i.e. this should have no impact to RTL, but it will again
have
impact to the common parts of the compiler, namely scanner, not to
target
specific units).
I can't remember the source, but my understanding is that Wirth
originally worked with an IBM 029 keypunch, possibly connected preparing
decks for a CDC. He specifically defined (* and *) as digraphs for { and
}, and I think there were others including (. and .) for [ and ] Did FPC
/ever/ fully-support these?
These should be fine (as easily confirmed by a short test program). I
actually use (* and *) for comments quite often to distinguish from other
comments using { and }. ;-) I'm not aware of a digraph for the caret sign
though which is (as correctly pointed out by you) missing in the EBCDIC
character sets specifically targetting English (and also Portuguese
apparently ;-) ) - it seems to exist in the International character
sets.
Tomas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On Wed, 18 Jan 2012, Tomas Hajny wrote: But then you are assuming the RTL should be using EBCDIC internally as well ? Obviously, that will be a lot more work. But I don't think this should be so. I may be overlooking something, of course. However: Our RTL is based on common (target specific) routines for reading (and writing) text and binary files (do_read do_write). You cannot translate between ASCII and EBCDID in these target specific routines because you don't know how the input would be used at that point (not even mentioning the fact that there is nothing like translation between ASCII and EBCDIC because there are multiple different character sets for both and real conversion isn't possible without taking this into account and knowing the real character sets which again depends on the context which is again not known at this low level). Once more: I do not think this is the task of the RTL. FPC and the RTL works with ASCII. That includes the expected contents of text files and whatnot. That a hypothetical FPC program opening an EBCDIC file on OS/370 needs to convert this to ASCII first is in my view the responsability of the programmer. The same goes for the FPC sources. I do not suppose that a FPC port would first convert the current ASCII sources to EBCDIC, but would continue to use the ASCII version. If you define the RTL as being able to handle EBCDIC on OS/370, it is a different matter, and a lot more work. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] estimating function code size
Hi all, In my project (win32) I need to estimate the number of machine code bytes of a certain function. The most straightforward option was to look for $c3 which is ret, and it worked on optimization levels O0 and O1. O2 and O3 seem to prefer $c2 $04 $00 (retn 4) instead. Then here comes win64, where the function end is marked by $c3 (ret) regardless of optimization level. And it turned out the opcode for mov eax,ebx also has $c3 in it. For now, I use O3 level and patterns $c2 $04 $00 and $5d c3 00 (pop rbp, ret) for win32 and win64 respectively, in hope that the function is always geting padded to (but not equal to) nearest $20 in size. This is far from deploying a full-fledged disassembler but is still not simple and elegant solution. I remember back in TP days there were methods for this, by using labels and addressing them with absolute keyword to obtain offset delta. I wonder if some similar trick can be used here, or if there are some built-in function to do just that? Thanks in advance. // Gennadiy ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] estimating function code size
Do you think it's granted that there is only one return in a function ? Maybe optimization or exit could create additional returns -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
Tomas Hajny wrote:
I can't remember the source, but my understanding is that Wirth
originally worked with an IBM 029 keypunch, possibly connected preparing
decks for a CDC. He specifically defined (* and *) as digraphs for { and
}, and I think there were others including (. and .) for [ and ] Did FPC
/ever/ fully-support these?
These should be fine (as easily confirmed by a short test program). I
actually use (* and *) for comments quite often to distinguish from other
comments using { and }. ;-) I'm not aware of a digraph for the caret sign
though which is (as correctly pointed out by you) missing in the EBCDIC
character sets specifically targetting English (and also Portuguese
apparently ;-) ) - it seems to exist in the International character
sets.
Some of the {$ directives apparently don't have (*$ equivalents. MACRO
if I recall correctly.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] estimating function code size
Do you think it's granted that there is only one return in a function ? Maybe optimization or exit could create additional returns Actually I do. Because I write this function :) It uses quite a lot of loops and ifs, but no exits. And what I need is a reliable way to get its code size at runtime without manually inspecting it on every rebuild. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] estimating function code size
On 2012-01-18 15:08, Gennadiy Poryev wrote: Do you think it's granted that there is only one return in a function ? Maybe optimization or exit could create additional returns Actually I do. Because I write this function :) It uses quite a lot of loops and ifs, but no exits. And what I need is a reliable way to get its code size at runtime without manually inspecting it on every rebuild. I had similar problem a year and a half ago. I ended up looking for ret using disassembler. Regarding one ret per function, I got this response from Jonas at that time: On 2010-07-18 15:42, Jonas Maebe wrote: On 18 Jul 2010, at 13:14, Žilvinas Ledas wrote: I want to use it this way: 1) Gel all @unitname.function addresses. 2) Use disassembler to find nearest next RET. 3) Then I assume that I have start and end of the function in the binary file. It works at least for the concept-showing app with some functions and enabled optimizations when compiling. Do I have some conceptual flaw? Yes: there is no guarantee that a function will contain only one ret (it is that way currently for compiler-generated code, but that can change at any time). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On Wed, January 18, 2012 13:56, michael.vancann...@wisa.be wrote: On Wed, 18 Jan 2012, Tomas Hajny wrote: But then you are assuming the RTL should be using EBCDIC internally as well ? Obviously, that will be a lot more work. But I don't think this should be so. I may be overlooking something, of course. However: Our RTL is based on common (target specific) routines for reading (and writing) text and binary files (do_read do_write). You cannot translate between ASCII and EBCDID in these target specific routines because you don't know how the input would be used at that point (not even mentioning the fact that there is nothing like translation between ASCII and EBCDIC because there are multiple different character sets for both and real conversion isn't possible without taking this into account and knowing the real character sets which again depends on the context which is again not known at this low level). Once more: I do not think this is the task of the RTL. FPC and the RTL works with ASCII. That includes the expected contents of text files and whatnot. That a hypothetical FPC program opening an EBCDIC file on OS/370 needs to convert this to ASCII first is in my view the responsability of the programmer. The same goes for the FPC sources. I do not suppose that a FPC port would first convert the current ASCII sources to EBCDIC, but would continue to use the ASCII version. If you define the RTL as being able to handle EBCDIC on OS/370, it is a different matter, and a lot more work. OK, could be, but not being able to work with text files created on that platform without additional effort on the _programmer_ side (not the RTL porter side because the RTL porter cannot address this easily within our current RTL structure as pointed out above) would hinder usability of such a compiler _a_lot_. It's certainly possible to start with that, but keeping it that way in longer term would considerably decrease the value of such undergoing in my opinion. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
2012/1/18 Tomas Hajny xhaj...@hajny.biz: ...except for the EBCDIC stuff, because the common parts of our RTL assume ASCII in many places If it was me implementing I would simply convert between both types everywhere necessary and leave the RTL using ASCII. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
Am 18.01.2012 14:08, schrieb Mark Morgan Lloyd:
Tomas Hajny wrote:
I can't remember the source, but my understanding is that Wirth
originally worked with an IBM 029 keypunch, possibly connected preparing
decks for a CDC. He specifically defined (* and *) as digraphs for { and
}, and I think there were others including (. and .) for [ and ] Did FPC
/ever/ fully-support these?
These should be fine (as easily confirmed by a short test program). I
actually use (* and *) for comments quite often to distinguish from other
comments using { and }. ;-) I'm not aware of a digraph for the caret sign
though which is (as correctly pointed out by you) missing in the EBCDIC
character sets specifically targetting English (and also Portuguese
apparently ;-) ) - it seems to exist in the International character
sets.
Some of the {$ directives apparently don't have (*$ equivalents. MACRO
if I recall correctly.
If some of the directives don't work with (*$ instead of {$ then these
should be reported as bugs.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
Am 18.01.2012 12:27, schrieb Mark Morgan Lloyd: I noticed that you wanted to add a unit i_i370 to the compiler unit and to the directory systems. This is wrong. The units listed in the compiler unit are the target operating systems (e.g. Windows, Linux, DOS), not the underlying architecture. Thus you'd only add a i_osvs1 (if I remember the name correctly) to that unit and directory, but you don't need to do this know as you first need to implement the architecture support. This architecture support is located in the corresponding CPU unit (e.g. ARM, PowerPC, i386, x86_64 (the latter two share the x86 directory as well)) and is included by using the cputarg in the unit compiler. This unit is located in the corresponding CPU directory. Thus I'd suggest you to copy the directory of an architecture (e.g. MIPS as this is a smaller and younger one) and name that i370 (now the unit output path I mentioned in 2 will make sense ;) ). Perhaps now would be a good time for a core developer to add appropriate definitions to trunk, so that anybody working on the IBM port only needs to modify files in a directory off ./compiler. What kind of definitons do you think of? I myself can't help with porting FPC to a new architecture, as I haven't done that yet (only to a new operating system target). But AFAIK Mark Morgan Lloyd worked on the MIPS target and of course there are compiler developers who implemented new architectures. Bearing in mind that what I was looking at was code that had already been working in version 1 of the compiler, which had been massaged into some sort of shape for v2. I can claim very little credit, it was entirely grunt work. More relevant might be Jonas's recent work targeting the JVM, but I suspect that the classic IBM mainframe architecture is probably nearer MIPS or 68K than to JVM or a modern RISC. By intuition I suggested MIPS as the base, because its a smaller target in FPC (and m68k is in no shape to be used as a base...). I don't know whether the high level code generator Jonas implemented for the JVM branch will be of any help here. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
Am 18.01.2012 12:51, schrieb Hans-Peter Diettrich: Sven Barth schrieb: 1. You wrote that you use the source code of FPC 2.6.0 and copied the compiler and rtl directories to some other workplace. I suggest you to use a SVN checkout of the development version (you can find the links here: http://www.freepascal.org/develop.var (at Connect to Source Repository with SVN)), because than you can more easily revert back something. Also there were quite a few changes from 2.6.0 to 2.7.1 and thus it's better to work with the most recent source. I wouldn't suggest to use 2.7 (trunk) as the development base, with Unicode and other features under development. Once a machine and RTL has been implemented for 2.6, it should not be so hard to merge it into trunk. I personally prefer to work in trunk no matter what. This way I can easily retrieve fixes for problems I encountered while developing my own feature, target, whatever. Additionally trunk has become quite stable again (here and there some hiccups because of the fpmake conversion, but they are usually fixed at the next day). I also would suggest git for all experiments, with better branch, merge and revert capabilites than SVN offers. Nevertheless the SVN server should be used as a base. I used git-svn quite successfully when working on generics. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
Sven Barth wrote: Perhaps now would be a good time for a core developer to add appropriate definitions to trunk, so that anybody working on the IBM port only needs to modify files in a directory off ./compiler. What kind of definitons do you think of? Absolute minimum, probably mostly makefile stuff so that make in ./compiler would correctly pick up ./compiler/s390, possibly initially populated with the MIPS stuff from trunk + my fudges. By intuition I suggested MIPS as the base, because its a smaller target in FPC (and m68k is in no shape to be used as a base...). I don't know whether the high level code generator Jonas implemented for the JVM branch will be of any help here. I think you're probably right. Of the architectures even part-implemented I think MIPS is about the nearest- certainly in terms of its register model. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding compiler directives?
On 18 Jan 2012, at 01:07, Paul Robinson wrote:
I would like to ask whether there's a rule or policy on new compiler
directives.
In general: the fewer, the merrier :)
The new directives are first, for printing capability:
Printing-related features is not something that we'd ordinarily put
into the compiler. Source code formatting (for whatever purpose) is
left to other -specialised- tools, such as
* ptop: general purpose source code formatter (included with FPC)
* Lazarus: includes various source code formatting capabilities
* maybe another tool not yet written, possibly based on other existing
code
Such tools could be extended to check for specially formatted comments
(such as { #PRINT ON }).
Then there is the second part of this inquiry which is:
$CROSS - various options I haven't decided yet
A most desperately missing feature - Cross Reference generation. I
can always write a cross-reference program, and in fact I'm working
on one because I can't find the nice one I had that was written
about 20 years ago that did much of what I'm thinking of now, but a
cross-reference function should be part of the compiler since the
compiler knows which reference the person is referring to
There is actually already some code for that in the compiler, although
it is quite outdated and no longer used. It's in the compiler/
browcol.pas unit. It writes (wrote) out symbol browsing information
that can (could) be used by the fp IDE. I don't think it included back
references from places where those symbols are used inside the code
though, only about where they are defined.
There's also the -vp compiler option, which writes out a file called
tree.log that represents the parse tree (this option primarily
exists to help debugging the compiler). It would not be very difficult
to extend that output with adding for each loadn also the unit/line/
column information for each referenced symbol. Its format was however
not designed to be easily machine-parseable, and changes from time to
time as fields get added to or removed from node types in the compiler.
There's also the Lazarus IDE, which already contains code to extract
all of tha information, both regarding definitions and uses (it needs
it for its code navigation functionality). So maybe adding some kind
of dump facility to that code would be better. In fact, in general
simply navigating the source code in Lazarus should offer you the same
information on demand as a separate cross-reference would (jump to
symbol definition immediately lands you at that definition, rather
than that you have to manually go looking through papers/source files
for the right source file and line number based on a comment).
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On Wed, January 18, 2012 11:22, Felipe Monteiro de Carvalho wrote: 2012/1/18 Tomas Hajny xhaj...@hajny.biz: ...except for the EBCDIC stuff, because the common parts of our RTL assume ASCII in many places If it was me implementing I would simply convert between both types everywhere necessary and leave the RTL using ASCII. As pointed out in my other e-mail, everywhere necessary implies either dear user, convert all your files from the original encoding before you want programs created in FPC to touch them or dear programmer targetting OS/370, make sure that your programs are limited in what RTL functions you use, or convert all locally stored files to ASCII and only use the RTL functions for text processing on the converted copies. Otherwise even stuff like line by line reading or field by field reading of the input text file using standard RTL routines may not work as expected with the current RTL. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
2012/1/18 Tomas Hajny xhaj...@hajny.biz: As pointed out in my other e-mail, everywhere necessary implies either dear user, convert all your files from the original encoding before you want programs created in FPC to touch them Yes, no problem here. I assume there must be some program in this platform which can edit ASCII text and another one (or the same) to convert text files between encodings. If not, just use the new port to cross-compile such a program =) or dear programmer targetting OS/370, make sure that your programs are limited in what RTL functions you use, or convert all locally stored files to ASCII and only use the RTL functions for text processing on the converted copies. Otherwise even stuff like line by line reading or field by field reading of the input text file using standard RTL routines may not work as expected with the current RTL. I don't see why. A text encoding is just a text encoding, of the hundreds of obsolete ones in existence, and the only sane way of handling text in cross-platform applications is Unicode. The RTL could ship with UTF-8 - EBCDIC convertor and define UTF-8 as the platform encoding. Detect which exact format the platform is using at runtime if necessary and convert everywhere necessary. This should cover all characters possibly imaginable and all control characters too. What could go wrong here? This is what Java does in all its platforms. As for WriteLn / ReadLn if one really wants to allow inputing directly control codes, one could either make them use UTF-8 and offer an alternative RawWriteLn / RawReadLn for raw input of control codes or leave them sending raw text and expose the routines to convert UTF-8 - EBCDIC -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On Wed, January 18, 2012 16:51, Mark Morgan Lloyd wrote: Sven Barth wrote: Perhaps now would be a good time for a core developer to add appropriate definitions to trunk, so that anybody working on the IBM port only needs to modify files in a directory off ./compiler. What kind of definitons do you think of? Absolute minimum, probably mostly makefile stuff so that make in ./compiler would correctly pick up ./compiler/s390, possibly initially populated with the MIPS stuff from trunk + my fudges. . . If Mark meant also addition of constants for a new architecture + OS combination(s), it's quite a bit of places already (I could find at least the following: compiler/systems.inc, compiler/systems.pas, compiler/utils/ppudump.pp, packages/fpmkunit/src/fpmkunit.pp and utils/fpcm/fpcmmain.pp plus creation of the corresponding subdirectory in the compiler directory; then there is also stuff like compiler/options.pas where TOption.WriteHelpPages and other places are currently still missing MIPS, compiler/msg/errore.msg, etc.). Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding compiler directives?
Am 18.01.2012 16:58, schrieb Jonas Maebe: Then there is the second part of this inquiry which is: $CROSS - various options I haven't decided yet A most desperately missing feature - Cross Reference generation. I can always write a cross-reference program, and in fact I'm working on one because I can't find the nice one I had that was written about 20 years ago that did much of what I'm thinking of now, but a cross-reference function should be part of the compiler since the compiler knows which reference the person is referring to There is actually already some code for that in the compiler, although it is quite outdated and no longer used. It's in the compiler/browcol.pas unit. It writes (wrote) out symbol browsing information that can (could) be used by the fp IDE. I don't think it included back references from places where those symbols are used inside the code though, only about where they are defined. I'm always fascinated by the little gems that are in FPC and the units that come with it (even if it might not work anymore as you wrote). :) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] estimating function code size
Hi,
On Wed, 2012-01-18 at 15:17 +0200, Žilvinas Ledas wrote:
On 2012-01-18 15:08, Gennadiy Poryev wrote:
Do you think it's granted that there is only one return in a function ?
Maybe optimization or exit could create additional returns
Actually I do. Because I write this function :)
It uses quite a lot of loops and ifs, but no exits.
And what I need is a reliable way to get its code size at runtime without
manually inspecting it on every rebuild.
try this:
{$CODEALIGN PROC=1} // force code alignment on 1 byte boundaries
var
size : ptruint;
procedure findmysize;
label
StartFindMySize, EndFindMySize; // actually things should work with
local labels too
begin
asm
call StartFindMySize
StartFindMySize:
popq %rax
movq %rax, size
end;
writeln('calculating size');
asm
call EndFindMySize
EndFindMySize:
popq %rax
subq size, %rax
movq %rax, size
end;
end;
procedure findmysize_dummy;
begin
end;
begin
findmysize;
writeln(ptruint(@findmysize_dummy) - ptruint(@findmysize), ' ', size);
end.
It shows two ways of doing this, with different disadvantages. The first
type is using assembler and calculating the range of addresses between
two labels. This has the disadvantages that it is platform dependent
(shwoing x64 code here, I'm sure you could make it more optimized),
and only calculates the distance between the two labels, i.e. without
entry and exit code. It is also always off by 5 bytes (single call +
address).
The other way is relying on the dodgy assumption that nobody changes the
order of functions in the object file or during loading or linking. This
is usually the case. It may not be completely safe, i.e. only work on
particular platforms etc., but usually it should be okay in the absence
of compiler options like e.g. smartlinking.
Further that while it includes method entry and exit code, it may not be
completely accurate due to the compiler aligning code
You may want to check the returned sizes by dumping the memory
containing the code using a debugger and choose the one which is more
suitable for you.
Thomas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
Felipe Monteiro de Carvalho wrote: 2012/1/18 Tomas Hajny xhaj...@hajny.biz: As pointed out in my other e-mail, everywhere necessary implies either dear user, convert all your files from the original encoding before you want programs created in FPC to touch them Yes, no problem here. I assume there must be some program in this platform which can edit ASCII text and another one (or the same) to convert text files between encodings. If not, just use the new port to cross-compile such a program =) Just a moment. Granted that everybody's favourite reference site is unavailable today, but minimal Googling suggests that MUSIC/SP- which I believe was Paul's OS of choice- supports web browsing etc. I think we need a reality check from Paul here, in case EBCDIC operation is mandated only by the emulator he was planning to use (whether I think his choice is good is irrelevant- lets try to get things like character set resolved before it causes any more sound and fury). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On Wed, January 18, 2012 17:32, Felipe Monteiro de Carvalho wrote: 2012/1/18 Tomas Hajny xhaj...@hajny.biz: As pointed out in my other e-mail, everywhere necessary implies either dear user, convert all your files from the original encoding before you want programs created in FPC to touch them Yes, no problem here. I assume there must be some program in this platform which can edit ASCII text and another one (or the same) to convert text files between encodings. If not, just use the new port to cross-compile such a program =) I don't know the typical situation on S/370 machines nowadays, so the following comment may not be valid. However: how likely would you be to use some new program if any interchange of files between this program and whatever other software used on your machine would require you to convert these files back and forth manually all the time (considering that the existing software may be the main reason for still using this kind of platform at all)? or dear programmer targetting OS/370, make sure that your programs are limited in what RTL functions you use, or convert all locally stored files to ASCII and only use the RTL functions for text processing on the converted copies. Otherwise even stuff like line by line reading or field by field reading of the input text file using standard RTL routines may not work as expected with the current RTL. I don't see why. A text encoding is just a text encoding, of the hundreds of obsolete ones in existence, and the only sane way of handling text in cross-platform applications is Unicode. My point is not about cross-platform applications here. My point is about applications running on zOS / OS/370 / ... natively (whether these applications should be cross-platform or not is the second step in my opinion). The RTL could ship with UTF-8 - EBCDIC convertor and define UTF-8 as the platform encoding. Detect which exact format the platform is using at runtime if necessary and convert everywhere necessary. This should cover all characters possibly imaginable and all control characters too. What could go wrong here? This is what Java does in all its platforms. I don't know how it works for Java, but I know that it cannot work transparently in current FPC RTL without making at least some changes in the common parts (platform independent so-far). Most likely something similar (i.e. changes to otherwise platform independent RTL parts) happened to Java too when ported to S/370, or the run-time part design included such kind of considerations from the beginning (which I personally doubt ;-) ). As for WriteLn / ReadLn if one really wants to allow inputing directly control codes, one could either make them use UTF-8 and offer an alternative RawWriteLn / RawReadLn for raw input of control codes or leave them sending raw text and expose the routines to convert UTF-8 - EBCDIC The point is not about the programmer interested in inputting the control codes directly (although that may be a valid scenario too if the programmer wants to work the same way he is used to on the other platforms), the point is about common parts of FPC RTL having e.g. hard-coded #9 as the tab character (which in turn controls how fields in text files may be separated from each other) or #10 as the line feed character and that this stuff happens at some point during transition from the generic binary file I/O to text file processing in common parts of the standard FPC RTL (as it stands now). BTW, even if one would consider e.g. translation from EBCDIC to UTF-8 in FileReadFunc (modified from its current standard platform independent implementation) because that is the place where generic files become to be interpreted as textual content in our implementation of standard Pascal RTL functions, it would fail in other routines in rtl/inc/text.inc due to difference between length read from the original file stored in EBCDIC and the size necessary in the text file buffer after the translation to UTF-8). Again - I'm sure multiple solutions exist, but I cannot imagine how it could work reasonably well without touching the common parts of the FPC RTL at least a bit (but unfortunately at multiple places which may be hard to find) except for a limited 'proof of concept' solution not meant to be used in standard ways (obviously, limiting all text file I/O to files encoded in ASCII or Unicode and not doing any console I/O if it cannot support ASCII or Unicode directly may be perfectly acceptable in such 'proof of concept' mode). Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
