Gpc September 2010

gpc@gnu.de

4 participants
7 discussions

Inefficiency of `mod'
by Emil Jerabek 25 Oct '10

25 Oct '10

Hi, during some debugging I noticed that GPC generates very hairy code for the `mod' operator with signed arguments. A closer look revealed that the code contains a lot of branching on conditions which can be determined on compile time, and most surprisingly, the value of X mod Y is recomputed _twice_, if X is negative. (I've attached a commented assembler dump.) This may be partially a back-end problem (CSE?), but I feel there's something wrong in the relevant code in gpc-common.c (build_pascal_binary_op) as well. `exp1 mod exp2' gets translated into something like exp2 <= 0 ? error : exp1 >= 0 ? exp1 mod exp2 : ((-exp1) mod exp2) == 0 ? 0 : exp2 - (-exp1) mod exp2 This arranges that both arguments supplied to the "internal mod" are non-negative, but this information is not passed on -- the arguments are still declared as signed types, which apparently makes the back-end to produce the mess it does. I've done a little test: the following replacement for `mod', which differs from the built-in one essentially just by the type-casts to `Cardinal', inline operator xmod (X, Y: Integer) = Z: Integer; begin if Y <= 0 then RuntimeError (714); if X >= 0 then Z := Cardinal (X) mod Y else begin Z := Cardinal (-X) mod Y; if Z <> 0 then Z := Y - Z end end; indeed generates a better code, it measures about 15% faster for positive X and more than twice faster for negative X. YMMV. If this is possible in user code, it should work in the compiler internals as well :) The result type of the whole `mod' expression looks dubious too. IIUIC, `exp1 mod exp2' inherits the type of exp1. Now, the result of `mod' is guaranteed to be nonnegative and to fit in the type of exp2 (or more precisely, it is in 0 .. High (type of (exp2)) - 1), whereas it needn't have anything to do with the type of exp1: consider var X, Z: Integer; Y: LongInt; begin X := -8; Y := High (LongInt); Z := X mod Y { -> overflow } end Or am I missing something? Emil (BTW, where is fjf434c.pas?)

10 16

Re: Null characters in strings
by Morton, John 12 Sep '10

12 Sep '10

My thanks once again. Things are now gradually starting to come together. I should first clarify that we never manipulate the time field - it's the precise 32-bit bit pattern (time) that gets sent to the outside world that matters, not what gpc Pascal (or any language/compiler) actually uses to hold the 32 bit time field. I am not yet a gpc user and was unaware of the type casting approach. (My last Pascal experience was some years ago and that was on mainframe/mini-computers, not in the PC/Linux world. Since then I've worked in ADA and greatly liked that language.) Type casting is exactly the KISS approach I was looking/hoping for. In great preference to the fragile and potentially non-portable approaches of variant records or the parameter mapping "trick" at the library interface. Also new to me are the gpc bitwise operators, thanks for mentioning them. They will be a great help in rewriting parts of our code. Once I get "Hello World" working I'll be spending some time with the current gpc manual to see what else in gpc is new to me. I expect I will find other things in gpc that will be of immediate practical use to us. Hopefully the manual also covers how to create GPC makefiles that use individually compile multiple source files, persistent object files and a separate user controllable linker step. As surmised, the time taken to build a message is not (yet) time-critical. However "endian-ism" might (but shouldn't) become an issue. We do not manipulate the time and not care how the bytes are actually stored because it's only the bit pattern of the "4 byte time field" that matters when the message is sent. The current conceptual model (without type casting) is: GetSystemTime( X ) - return 32 bit time in X (as a 4 byte string) Y = X + rest-of-message - concatenate strings to get final message string SendMessage( Y ) - hardware sends the final message sting As revised to use type casting (using the types at the end of this message): GetSystemTime( Z ) - return the time in Z (Z is defined as 32 bits) X = Char4( Z ) - cast the 32 bit time to a 4 byte string Y = X + rest-of-message - concatenate strings to get final message string SendMessage( Y ) - hardware sends the final message string So why use a 4 byte string and not something else? Everything else in the application uses strings - which makes using a string the simplest way for us to handle the 32 bit time field. Comments? Improvements? Thanks. BTW, My viewpoint is that if something can be done in an easily understood (=KISS) manner using only standard gpc Pascal constructs (i.e. without "tricks" or "virtuous" (=often obtuse) coding) it is "pure" Pascal. By those standards only the second version is "pure" Pascal. -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Frank Heckenbach Sent: September 7, 2010 08:03 PM To: gpc(a)gnu.de Subject: Re: Null characters in strings Morton, John wrote: > My thanks for confirming that writeln is not implemented using C's > printf function (I can't remember where I got that idea) and that gpc's > writeln can send all 256 characters (absolutely necessary to handle > binary time as a string). > > On reflection I realize I have misstated our problem. But I think I > also have a work-around for it. > > The issue is that the supplied library returns the time as a 32 bit > binary value. The problem is essentially how to coerce the 32 bits into > a corresponding 4 character gpc string. (BTW, they are the first 4 > bytes of every message sent by our application). > > I had hoped that the coercion (effectively a type cast) would be easy to > accomplish within Pascal. I then thought about variant records but that > did not seem feasible. > I have since realized that the conversion could be done where we define > the interface to the external routine. In the Pascal function > definition use a 4 character fixed length string for the time field and > have the linker map that string to the corresponding 32 bit value field > used by the library (probably by using pass-by-address, possibly > pass-by-value). > Not a pure Pascal approach but a practical one - as long as you are well > aware of the pitfalls. (In the "pure" approach the Pascal interface > parameter would be a 32 bit unsigned value that gets converted/mapped by > Pascal to the corresponding 4 byte string). The only "pure" Pascal approach would be converting the value to single bytes using "div"/"mod" (GPC also supports bitwise "and" and "shl"/"shr") and then to characters using "Chr". If it's not time-critical, this might actually be worth considering, since it avoids endianness issues. With GPC, also type-casting should work. Something like this: program Foo; type Card32 = Cardinal attribute (Size = 32); Char4 = array [1 .. 4] of Char; var a: Card32; b: Char4; begin b := Char4 (a); a := Card32 (b); end. Variant records are sometimes abused(!) for this purpose, but I don't recommend it. Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

2 1

Re: Null characters in strings
by Morton, John 08 Sep '10

08 Sep '10

My thanks for confirming that writeln is not implemented using C's printf function (I can't remember where I got that idea) and that gpc's writeln can send all 256 characters (absolutely necessary to handle binary time as a string). On reflection I realize I have misstated our problem. But I think I also have a work-around for it. The issue is that the supplied library returns the time as a 32 bit binary value. The problem is essentially how to coerce the 32 bits into a corresponding 4 character gpc string. (BTW, they are the first 4 bytes of every message sent by our application). I had hoped that the coercion (effectively a type cast) would be easy to accomplish within Pascal. I then thought about variant records but that did not seem feasible. I have since realized that the conversion could be done where we define the interface to the external routine. In the Pascal function definition use a 4 character fixed length string for the time field and have the linker map that string to the corresponding 32 bit value field used by the library (probably by using pass-by-address, possibly pass-by-value). Not a pure Pascal approach but a practical one - as long as you are well aware of the pitfalls. (In the "pure" approach the Pascal interface parameter would be a 32 bit unsigned value that gets converted/mapped by Pascal to the corresponding 4 byte string). Anyone have any thoughts on this? Have I have missed a simpler approach? John. -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Frank Heckenbach Sent: September 3, 2010 05:16 PM To: gpc(a)gnu.de Subject: Re: Null characters (& string Morton, John wrote: > We have encountered an unexpected implementation issue with gpc, one > that probably affects all languages implemented using C/C++: The > mapping of Pascal writeln (etc.) statements to "equivalent" C/C++ string > handling code. Others have replied already, but I can confirm that GPC does not use printf etc. internally to implement WriteLn, if that's what you mean. > Stated more generally, is there a pure gpc Pascal way to send > ("writeln") strings that can contain any/all of the 256 8 bit characters > (especially the null) - an approach that does not require retyping our > string definitions? Of course, any such way is not pure Pascal in the sense of ISO Pascal or so. Text files (WriteLn) are not really meant for binary data, though it works with GPC, and is as portable as GPC is, and probably works with some other compilers as well. The official Pascal way would be a "file of Char" (though ISO Pascal doesn't even guarantee that the NUL character is part of the character set), where you'd need to read/write every character individually. Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

2 1

Null characters (& string implementation) in gpc
by Morton, John 03 Sep '10

03 Sep '10

We have encountered an unexpected implementation issue with gpc, one that probably affects all languages implemented using C/C++: The mapping of Pascal writeln (etc.) statements to "equivalent" C/C++ string handling code. We have not found a pure (Pascal-only) way to use gpc writeln (etc.) statements to send strings that must include null characters (in our case as part of a 4 byte binary time). The problem is that the implementation of the mapped C/C++ function prematurely terminates a message at the null, preventing the message from being transmitted properly. The impact on us is that whenever any byte of the time rolls over a service outage results - with the length of the outage depending upon which byte rolls over. We have since kluged a way around the issue but would much prefer a pure Pascal (=portable) solution. In our case the message must be sent as one complete entity, meaning separating the string into multiple "writeln" statements is not possible. (This would be an awkward approach if/when (multiple) nulls can appear anywhere in the string). Stated more generally, is there a pure gpc Pascal way to send ("writeln") strings that can contain any/all of the 256 8 bit characters (especially the null) - an approach that does not require retyping our string definitions? Any ideas out there about how to do this? Thanks.

4 3

Re: Null characters (& string implementation) in gpc
by Morton, John 03 Sep '10

03 Sep '10

Bonjour Maurice, I can't test gpc until I build "Hello world" (or "bug") so your results are great news for us. Our problem may have something to do with the FAA library and the way we had to link it to our code. More likely it's because we have a quite old version of gpc and the problem we encountered was fixed in a subsequent release. We'll see if the problem disappears after we rebuild our application using the new version of gpc (once I get it going). Merci. -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Maurice Lombardi Sent: September 3, 2010 01:29 PM To: gpc(a)gnu.de Subject: Re: Null characters (& string implementation) in gpc Le 03/09/2010 17:23, Morton, John a écrit : > We have not found a pure (Pascal-only) way to use gpc writeln (etc.) > statements to send strings that must include null characters (in our > case as part of a 4 byte binary time). The problem is that the > implementation of the mapped C/C++ function prematurely terminates a > message at the null, preventing the message from being transmitted > properly. > I do not understand. The following test program works as expected: program bug; var s: string[255] = 'hello >'+chr(0)+'< world'; begin writeln(s); end. there is an unprintable character between the two > < and redirecting the output to a file which can be examined with a binary editor shows that this character is indeed a null. Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

Why GPC? (was: GPC linker errors - help needed)
by Morton, John 02 Sep '10

02 Sep '10

Quite reasonable questions. And No, you didn't miss anything. Yes, we need to use static libraries/objects that we can place under configuration control. And static linking is mandatory for us. That's why I have used "rpm2cpio" to extract the 3 objects from "glibc-devel" that are used by gpc. Now I just have to figure out how to get gpc to use these 3 files and how to split gpc into separate compile and link phases and also get gpc to place the object files into their own permanent folder. Once that is done I should be able to rebuild our application on RHEL 5.4. Any hints here would be greatly appreciated. I agree with your point about commercial software but the choice of O/S, compiler, etc. was determined by the FAA, not us. They also provide us with a special purpose library that we must use (link to) when interfacing to their systems. That library pretty much forces us to use gpc and/or other gnu-based tools/compilers (gcc, gnat, etc). Gpc is being used for compatability to the library and because that is what was used to port our Pascal interface code (originally developed for HPUX in the mid 90s) to 32-bit RHEL. The reason behind behind what we are doing is that the FAA is moving a system we use to 64-bit RHEL5.4. The nature and importance of this system means we must move in lockstep with them. Part of our effort requires porting (for the second time) the existing code and development tools. While the current 32-bit executable should run without problems on RHEL5.4 we will have to maintain and upgrade this software for many years. BTW, I hope everyone understands that I have to play Devil's Advocate and think of the worst possible outcome that would occur if all the holes in the "Swiss Cheese" model line up. I only handle one of many slices; if any other slice blocks the hole in my layer then there is no safety issue. -----Original Message----- From: Hiltibidal, Rob [mailto:Rob.Hiltibidal@argushealth.com] Sent: September 1, 2010 05:10 PM To: Morton, John Subject: RE: GPC linker errors - help needed I think I missed something here... Why not use static libraries at this point? In all honesty if its safety/life-critical systems why not use commercial software that is supportable?

1 0

Re: GPC linker errors - help needed
by Morton, John 01 Sep '10

01 Sep '10

The reality of working with safety/life-critical systems means it very dangerous for us to use shared libraries. I understand the point about dependencies and the concerns expressed about extracting object files. But in my world the concerns are precisely opposite. It is safe to extract/use an object file (which can be properly controlled) and extremely unsafe to use a shared library (because other applications may "update" the library). BTW, Extracting the objects from the library shouldn't matter. If the object files were created as expected, all external references/definitions that they need will be satisfied during the link phase. Besides, if the object files do have dependency problems the application will not link - which is much, much safer than the standard situation. In my world a change to a shared library automatically destroys application certification - and the change can make every application that uses that library dangerous to the public. My problem right now is the dependency tree prevents the installation of "glibc-devel". However it looks like I can use the RPM "--nodeps" option to force Red Hat's "glibc-devel" package to install on my system. A better approach seems to be to use "rpm2cpio" (see http://www.rpm.org/max-rpm/s1-rpm-miscellania-rpm2cpio.html) to do the extractions. Has anyone tried this tool? If the "rpm2cpio" approach doesn't work we will probably have to force the install and handle the "glibc-devel" package like any other non-gpc library, see below. To meet our safety requirements we will have to place copies of the 3 object files - and all other non-gpc items (shared files/libraries, tools, etc.) used to build the application - into non-shared (= non-standard) locations, then instruct the linker to look for these files in their new location. And everything involved (including all gpc components) will be placed under configuration control. The end result is that our installation of gpc would become "Stand-Alone" and immune to changes to shared software. This also seems to be the easiest way to make use of the "shared" files while still meeting our safety (and other) requirements. Critically for us, this approach also ensures that several years from now that nothing has changed and that we can recreate an absolutely identical executable of our application, starting from nothing. The necessity to override standard locations with non-standard ones is another reason why it is important for gpc compiles to be separated into totally separate compile and link phases (e.g. two command files, normally invoked automatically, one after another). I suspect separating the gpc command into two separate compile and link command files is more complicated than just putting the commands (displayed by gpc -v) into separate files. For instance I don't see "hello.o" being passed to the "collect2" (the linker?) command and there also is the issue of how to handle/pass the temp files used by gpc. Does anyone have any experience in doing this? Thanks. -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Jonas Maebe Sent: August 27, 2010 05:04 PM To: GNU Pascal mailing list Subject: Re: GPC linker errors - help needed On 27 Aug 2010, at 22:24, Morton, John wrote: > As expected "glibc.i686" was preinstalled. I tried installing the i386 > and x86_64 Red Hat rpms for "glibc-devel". Both rpms reported some > unsatisfied dependencies. To make a long story short, in both cases the > geometric growth of the dependency tree looks like it will eventually > force all of the gcc C compiler to be installed. > Maybe it's my non-C background but this hidden 3 file dependency (upon > C) seems unreasonable given that all that gpc needs (see output below) > is for those object files to be visible to the ld linker (assuming these > object files are not dependent upon other files). I would strongly recommend to simply install all dependencies. While things *may* work fine with just those files, they may just as well not for one reason or another. You can only make things more difficult for yourself by trying to circumvent the the dependencies of those packages. Jonas

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc September 2010