Gpc July 1998

gpc@gnu.de

19 participants
25 discussions

Re: LongestReal problems
by Frank Heckenbach 12 Jul '98

12 Jul '98

Marius Gedminas wrote: > I have written an expression parser and evaluator in Borland Pascal and I do > not use calculators any more (besides most of them do not have 18 digit > precision, not to mention another functionality). In the past I have relied > on BP run-time system to show only `accurate' (I hope you understand what I > have in mind ;) digits and it would be very great if I could rely on GPC too. > I do not request this to be the default behavior, but I would want to know of > a way to achieve it. The file float.h contains a number of useful constants, e.g. {FLT,DBL,LDBL}_MANT_DIG for the number of digits is the internal radix, and even {FLT,DBL,LDBL}_DIG for the number of decimal digits. (You may have to generate a correct version with enquire -- e.g., mine had the same values for long reals as for reals. I wonder if the GCC installation shouldn't do this automatically.) So, there's only the problem how to get the constants into a Pascal program: - Directly including the file doesn't work because of the C comments in it. (BTW, how about an option for the Pascal preprocessor to accept C comments? AFAICS, they can't occur in a legal Pascal program, anyway.) - One could write a small C wrapper, as always. - The GPC installation could Pascalify this file, i.e. remove or Pascalify the comments, remove the "F" and "L" postfixes from some numbers, and perhaps translate the defines into constants and make a unit out of it. This does not seem very difficult to do. I think the following sed script should do the job -- at least it does on my machine (sorry for the long line ;-): sed 's,/\*,{,;s,\*/,},;/^#undef/d;/FLOAT_H/d;s/float\.h/Automatically generated from &/;s/#define[[:space:]]*$[A-Za-z0-9_]*$[[:space:]]*$[-+0-9.Ee()]*$[FfLl]\?$/const \1 = \2;/' The resulting declarations could be merged with the RTS, e.g. by including them into into gpc.pas which contains most RTS declarations. So, we only have to tell the makefiles to do this, and then, I think, it would be the best solution. Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

RE: EFLIB as class library for Object-Pascal
by Johan Larsson 12 Jul '98

12 Jul '98

Hi Frank and Everyone, Sorry for the late reply, but I had better wait for the legal matters to settle. There are now news for those that are interested in EFLIB as a free Object-Pascal R&D cross-platform. EFLIB prototype 6 is my ongoing master thesis and research project seen at: http://ftp.sunet.se/EFLIB/Introduction.html http://ftp.sunet.se/Documentation/Technology/ [ In short to newcomers: it is all about flexibility, reuse, object-orientation, data structures, cross-platform technique, aesthetics, mathematics, numeric, generic programming and GUI/HCI. We still need collaborators, especially for database support and CORBA. ] Frank Heckenbach wrote 980507: > I appreciate that it will be free software. However, due to the > recent creation of the NPL, MPL and other more or less compatible > free licenses, I'm a bit wary that it will really be a GPC compatible > license. I looked at the license mentioned above, but I'm not a > lawyer :-), therefore I'd like to see an official statement > confirming the possibility to combine it with GPL/LGPL licensed > software (i.e. to use and distribute without conflicting with > either of the licenses). I hope this will be possible. The new license agreement should be fully compatible with GNU GPL (but maybe need some more adjustments) and is according to Richard Stallman fully compatible with GNU LGPL. Peter has helped me to adjust it too. See for yourself at: http://ftp.sunet.se/EFLIB/Legal/License/ > GPC is also about platform independence and easy to integrate with > other languages, so this could be a good combination. :-) Indeed - since EFLIB, with help from Miroslav Kharchuk and Michael Van Canneyt, will support Delphi VCL though built on top of a much more modern GUI cross-platform technology, we can actually create a complete FREE platform for Object-Pascal development! > These things are actually planned for GPC: > > - Properties > - Classes > - Exception handling Frank, this is excellent! These things are all you need for EFLIB to run natively under both GNU and FPK Pascal. Please inform me about the progress! I'd be happy to deliver a standard framework / class library for your excellent compiler. I offer you the ability of changing EFLIB designs according to your personal preferences -- but I would appreciate to hear all your comments ASAP since the architecture must settle soon. Please direct them to: eflib-developers(a)acc.umu.se. Yours Sincerely, Johan Larsson <jola(a)csd.uu.se> PS. Please CC to my mailbox - I cannot subscribe due to the flow of incoming messages. Sernanders vÃ¤g 8:241 - SE-752 61 UPPSALA - SWEDEN Phone +46-18-460046 - WWW http://www.csd.uu.se/~jola/ Also, see EFLIB on the Internet at http://ftp.sunet.se/EFLIB/Introduction.html

1 0

Re: LongestReal problems
by Peter Gerwinski 11 Jul '98

11 Jul '98

Hi, Marius! Let's rather continue this discussion on the list. Be invited to bounce my article there if you reply publicly. > Perhaps in the distant future `LongestReal' will have greater precision > than `Extended' ;) Yes, I expect that too. That's why we have `LongestReal' as an alias for `LongReal' (= `Extended'). > I understand that. But how can I determine the precision of data in a > portable way? I don't know right now, but it should be possible. With high probability, someone on the list knows a way. > The goal I'm trying to achieve is to get the value of a real > number to a string in a not-scientific notation with highest possible > precision. You can't do it this way. In order to express some numbers represented in one system (say, the binary system) you need an infinite number of digits to express it in another system (say, the decimal one). 1/3, for instance, is a finite fraction in a system based on 3. > [...] > I agree with the first half: BP should also output 70 digits (add some > zeroes, for example). Zeros would be intuitive, but simply wrong in most cases. > I see that I should have asked this question in another way: how to get > decimal representation of a real number with maximum precision. You can't without loss of precision. A hexadecimal representation would do it. Greetings, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980511 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

2 1

LongestReal problems
by Marius Gedminas 10 Jul '98

10 Jul '98

From: Marius Gedminas <mgedmin(a)pub.osf.lt> To: gpc(a)hut.fi Cc: Bcc: Subject: LongestReal problems Reply-To: Hi, developers! DJGPP version of GPC-980511 complains when I try to use ArcTan function on LongestReals (in fact is is `ld', not `gpc', which complains). The error message is as follows: c:/djgpp/lib/gcc-lib/djgpp/2.81/libgpc.a(pp_ARCTAN.o)(.text+0xd):rts-emath.c: undefined reference to `tanl' c:/djgpp/lib/gcc-lib/djgpp/2.81/libgpc.a(pp_ARCTAN.o)(.text+0x29):rts-emath.c: undefined reference to `tanl' Another (unrelated) problem: let's say we have a source like this: program StrangeLongReals; { This compiles both under GPC and Borland Pascal } {$IFNDEF __GPC__} {$N+,E+} {$ENDIF} var R: {$IFDEF __GPC} LongestReal {$ELSE} Extended {$ENDIF}; begin R := 0.123451234512345; WriteLn(R); {--- Correct } WriteLn(R:0:70); {--- Prints lots of random digits } R := 0.1234512345123451234512345; WriteLn(R); {--- Correct } WriteLn(R:0:70); {--- Prints lots of random digits } end. When compiled with Borland Pascal I get the following output: 1.23451234512345E-0001 0.123451234512345000 1.23451234512345E-0001 0.123451234512345123 And GPC version gives: 1.234512345123450e-01 0.1234512345123449999978669759571270816137668263830656896932817737042602 1.234512345123451e-01 0.1234512345123451234478368405878757685782057823543386991840842994341343 I don't know if this is a bug or a feature, but I would prefer the behavior of BP. Yours, -- Marius Gedminas "A Hacker is any person who derives E-mail: mgedmin(a)pub.osf.lt joy from discovering ways to WWW: http://www-public.osf.lt/~mgedmin/ circumvent limitations." rab'86

2 1

unsubscribe
by dtroeger＠ix.netcom.com 10 Jul '98

10 Jul '98

Please unsubscribe me --

1 0

GPC compiler errors
by Thamm, Russell 09 Jul '98

09 Jul '98

I recently installed Gnu Pascal (DJGPP-MSDOS) and was appalled at the fragility of the compiler. I had enormous problems with procedural-parameters, file types and proper accessing of types defined in Units. Eventually, I downloaded the latest alpha (gpc-980511.i386-pc-msdos-djgpp.zip) and am delighted that this version will at least compile my program. If someone could tell me where to get the crtf.o file, the linker keeps asking for, I might even be able to see if the code actually runs. The compiler still apparently has problems with type definitions in units. I have a program that uses two units: 1) pktdefs - type definitions 2) frames - unit to handle access to large data files The frames unit declares an object that has a method: function GetNextDataPkt(VAR pkt : PacketPtr) : BOOLEAN; The type PacketPtr is declared in pktdefs and my main program and frames USE pktdefs. When my main program tries to call GetNextDataPkt, I get a compiler error: Error: type mismatch in argument 2 of `Tframes_Getnextdatapkt' The code in question is: while MyFrames.GetNextDataPkt(pp) do If I move the PacketPtr declaration into frames.pas, the compiler error disappears. I don't know how there can be an error in argument 2 of a function with only one parameter. Perhaps the return value is argument 1. However, the compiler apparently thinks that the type "PacketPtr" used in frames is different from "PacketPtr" used in the main program, even though both "import" the declaration from the same unit. Russell Thamm

3 2

Re: gpc on AIX: troubles!
by Frank Heckenbach 07 Jul '98

07 Jul '98

Nick Cremelie wrote: > > A clever idea! The problem is to get the parameters right. The > > above work for text files, but they're a bit unusual (and I wonder > > why GPC uses them for Input and Output). > > So do I. But if I set them to e.g. 256,1 ("large" buffer, type text > files), it didn't work. So I just took the values as for Input, Output). The "buffer" is not a temporary buffer like in BP (if you know that), but Standard Pascal's file buffer. For text files, this must be a char, i.e. 1 byte, or 8 bits (where bits are indicated by the bit with value 2 in the flags), otherwise the routines won't work properly. > I'm not familiar with assembler listings, but I definitely see _p_initfdr > somewhere in there. But don't forget that Input and Output are always > initialized with that function. That's different as their _p_initfdr calls are done from another RTS function, not from the program. OK, I now have a suspicion what's wrong. I think both problems are related, and they're not really I/O problems, but due to the fact that the initialization code of the program is not executed. Please try the following things: - writeln (s.capacity), where s is a global string variable. If my theory is correct, it should write 0 or some nonsense value, instead of the correct capacity. That's why a wrong value will be passed to the read routine, and the varargs are not guilty. - s.capacity := 255 (or whatever your capacity is) before the read. Then the read should work. This can serve as a workaround, just like the explicit InitFDR, until the real problem is found. - Move all the code and (especially!) the variable declarations into a procedure. Then, both issues should be OK. - Try a unit (or module) with initialization code, e.g. the following: file foo.pas: program foo; uses bar; begin end. file bar.pas: unit bar; interface implementation to begin do writeln('Hello, world'); end. Then `gpc foo.pas bar.pas' or `gpc --automake foo.pas', and see if it writes anything. - Try your test program (one with a global file variable) with RTS debugging. That's a little more complicated: - change into p/rts and `make clean' - change back into the main (GCC) source directory and `make LANGUAGES="pascal" CFLAGS="-O2 -DDEBUG"' Perhaps you'll get an error about an undefined `_p_rts_version' in rts-rt0.c -- in this case replace this by `gpc_rts_version'. I hope you won't get any other errors. - install GPC - compile your program with the new GPC - run it with the command line options `-Grts -ddddd', and send me the output Now for the reason why the initialization code of the program is not executed. I think I have got bad news: As far as I understand the remarks in the GCC doc (see `info -f gcc -n Initialization'), this feature is not needed in C, and therefore has not been ported to all platforms. :-( To confirm that, I checked config/rs6000/rs6000.h (which is included by the config/rs6000/aix*.h files), and it contains: #define ASM_OUTPUT_CONSTRUCTOR(file, name) #define ASM_OUTPUT_DESTRUCTOR(file, name) IOW, it just ignores the initialization and finalization code! Great, isn't it? :-( So, what can be done: - Implement this feature for your platform. But since you don't program in assembler, I don't suppose you know how to do this. I don't, either, but I suppose it's even more difficult than "ordinary" assembler programming... - Find someone to implement it, perhaps in the GCC mailing lists or newsgroups. But seeing how much most C programmers "love" Pascal, I wish you best luck... - Do it otherwise. Peter and I already discussed how to implement the initialization and finalization code with constructors and destructors. Actually, this was last week, and we were thinking about long-term ideas. We didn't expect it would come back to us so soon... Since most of this work would probably have to been done by Peter, I can't say how soon or late he can do this, but I fear, not so soon... Here's another possible workaround: Don't use units or modules with initializers or finalizers (if you need them, put the code into procedures, and call them manually). For the program's initialization, insert the following into your program's declarations: { Dirty workaround for GCC bug } var p_collect_flag : asmname '_p_collect_flag' Integer; procedure program_initialize; asmname '__init_program_Foo'; where Foo is the name of your program with the first and only the first letter capitalized, no matter how you capitalized it in the "program foo;" declaration. Immediately after the main "begin", add: p_collect_flag := 0; program_initialize; That's not very nice, I know, but it might work... To test it, try the following program. It should output 0 and 42. program foo; { Dirty workaround for GCC bug } var p_collect_flag : asmname '_p_collect_flag' Integer; procedure program_initialize; asmname '__init_program_Foo'; var s : string (42); begin { Simulate on my platform the missing initialization and test it } s.capacity := 0; writeln (s.capacity); { Now do the initialization manually } p_collect_flag := 0; program_initialize; { Test it } writeln (s.capacity); end. The only thing I can do to simplify this is to let the RTS clear the p_collect_flag. That's what I did now, so with the next GPC version, it could work without the two lines referring to p_collect_flag. > > Also, did you get any warnings (especially of type mismatches and > > the like) when compiling the RTS? This might indicate some non-portable > > type conversions in the C files. > > These are all the warnings I got during the stage2 build for c and > pascal using the stage 1 gcc-2.8.1 compiler (I didn't really worry > about them, they did not seem too severe): Most of the warnings are (a) known, (b) unrelated to the problem and (c) fixed in the next version. :-) Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Re: gpc on AIX: troubles!
by Frank Heckenbach 06 Jul '98

06 Jul '98

Nick Cremelie wrote: > > Not really with bindings, but anyway: There's a known bug "On IRIX work > > stations, _p_initfdr() must be called manually" on the To-Do list. > > So, I'm adding AIX there. I don't know anything about these architectures, > > but I agree that fixing this would be a good idea... :-/ > > I don't see how I can call _p_initfdr() manually. From within the > Pascal program, the compiler complains when I call that function. When > I try to call InitFDR (defined in p/rts/gpc.pas I thought), the compiler > says: > > txtfile.pas: In function `Assign': > txtfile.pas:16: undeclared identifier `Initfdr' (first use this function) > txtfile.pas:16: (Each undeclared identifier is reported only once > txtfile.pas:16: for each function it appears in.) > > So how do I call initfdr manually??? Yes, the above description for the work around is a bit too simplistic. If you want to call it from Pascal, you have to copy the declaration of InitFDR from gpc.pas, or add an "uses gpc;" to your program (however, the latter is not yet completely worked out, so it may cause some name conflicts). > As you will recall, I had problems with gpc on AIX when opening > files. I made a little change in rts-file.c: I replaced line > 370: > > _p_generic (701); /* FDR not initialized */ > > with > > _p_initfdr(File,filename,8,0xf); > > This means: if m_SIZ(File) == 0 (indicating that _p_initfdr was > not called), I call it with a standard buffersize and flags). > This enables me indeed to open files for reading and writing! > However, I have no clue about the impact of this change. A clever idea! The problem is to get the parameters right. The above work for text files, but they're a bit unusual (and I wonder why GPC uses them for Input and Output). The following are the parameters GPC uses for the different kinds of files -- however, they're subject to change in future versions, but not too soon (i.e. not until GPC version 2.1): Text files (text): 1, 1 Typed files (file of foo): Sizeof(f^), 0 Direct typed files (file [bar..baz] of foo): Sizeof(f^), 16 Untyped files (file) (BP extension): 1, 64 For "external" files, i.e. those declared in the program header, add 4 to the last parameter. The second parameter is actually the internal file name (i.e. the name of the variable as declared in the program), but it's only used for the Standard Pascal feature of asking the user for a name for file "foo", and for some error messages. But it seems strange to me in the first place why _p_initfdr() isn't called automatically -- after all, the compiler (util.c, function init_simple() generates code to do so). Could you generate an assembler output of your Pascal program (gpc -S), and check if it contains some calls to _p_initfdr(), and if so, what parameters are pushed before it. > But then we noticed something else: reading a string (string[255]) > with readln (from file or stdin) always returned an empty string, > although eoln and eof are set appropriately (so it is actually > reading the file!). We checked and noticed that the argument maxlen > to _p_reads in rts-rdsub.c is always zero. Question: would this be > because va_arg (which gets maxlen from a variable argument list) doesn't > work probably, or because the variable argument list is not set > properly when calling _p_read in rts-read.c ? Could you please check which parameters are pushed before the call to _p_read() in the assembler code of your program (or just send me the assembler file if that's easier to you)? For another test, you could check the value of s_maxlen in the READ_STRING macro in rts-rdinc.c (with some printf) and see if it's already wrong there. (I suppose it is, but one never knows...) Also, did you get any warnings (especially of type mismatches and the like) when compiling the RTS? This might indicate some non-portable type conversions in the C files. Perhaps really the varargs are to blame -- I don't know much about their inner workings. I intend to get rid of them, anyway. If they're the problem here, this might be a reason to get rid of them even earlier than planned... Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Re: installing gpc on SGI under Irix5.3
by Kevin A. Foss 05 Jul '98

05 Jul '98

On Sun, 5 Jul 1998 12:13:51 +0200 (MEST), Peter Gerwinski wrote: >According to Robert P. Ewing: >> I get: >> gpc: installation problem, cannot exec 'as': No such file or directory. >> >> Looking in the /usr/local/bin directory shows I have gpc, but nothing >> else (no as, no ld...). > >Your system's `as', `ld' etc must be installed somewhere (e.g. in >/usr/bin); please try to find out their place. It is also possible >to use the GNU versions of those programs; in that case you have to >`./configure' GPC with `--with-gnu-as' and/or `--with-gnu-ld' and >to provide the corresponding packages. I haven't used an IRIX machine in years, and even then it was quite brief. However it is important to note that SGI led the pack as far as commercial vendors un-bundling parts of their UNIX implementations. Most notably, such rarely used items as the development tools. :) With 5.3 they don't even ship the C headers and runtime libraries, so I wouldn't be surprised if "as" wasn't in the base OS either -- or at least not in the default install. Most versions of gcc for IRIX on the net use gnu-as from what I can tell. Hopefully someone more familiar with IRIX knows better. 'ld' should definately be someplace on his system. Try out this site for IRIX freeware (including gcc information): http://reality.sgi.com/ariel/freeware This site has the SGI/IRIX faqs: http://www-viz.tamu.edu/~sgi-faq/ Again however, GCC for IRIX 5.3 is DOA unless you bought the development disc -- which is going to make it difficult to recompile GPC to use gnu-as. I would suggest the original poster ask his system administrator what exactly he can expect to find on his system. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net

1 0

gpc on AIX: troubles!
by Nick Cremelie 05 Jul '98

05 Jul '98

Hello all, I downloaded the most recent version of gpc, available at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ (gpc-980511) and I also got gcc-2.8.1. I tried to make gpc on an RS/6000 with AIX4.1.4, using gnu make 3.76. This is the result at a certain stage during the make: ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototy pes -Wmissing-declarations -g -O2 -I. -I../.. -I/backup/gnu/gcc-2.8.1/p/rts/.. /.. -I/backup/gnu/gcc-2.8.1/p/rts/../../config rts-base.p rts-base.p:56: warning: no previous prototype for `__init_Rts_base' xgpc: Internal compiler error: program gpc1 got fatal signal 6 gmake[1]: *** [rts-base.o] Error 1 gmake[1]: Leaving directory `/backup/gnu/gcc-2.8.1/p/rts' gmake: *** [libgpc.a] Error 2 Again, an Internal Compiler Error seems to be the problem, just as it was the case with gpc-971001. My debugger can't find much useful information in the core. A "where" just shows me this: __start() at 0x100001c8 How do I solve this problem???????????? Please reply by mail as I'm not yet subscribed to the mailing list. Nick Cremelie

4 12

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 July 1998