Gpc June 1997

gpc@gnu.de

25 participants
172 discussions

Re: Bug fixes (was: "Recursion, need more stack space.")
by PredatorZeta 16 Jun '97

16 Jun '97

Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: > Or else: Loading the memory reference into a register and > pushing that *might* be faster than a direct push (don't know). Just little clarifying.....:)) No. Surely not on 80x86 machines. Look this (is for Pentium): 1 push (mem) take 2 cycles NOT pairable 2 a) mov (mem), reg take 1 cycle pairable AGI Stall (1 cycle+cut off pairing system) b) push reg take 1 cycle pairable TOTAL: 3 cycles Well, is 2 (not pairable) versus 2 1/2 (not pairable) cycles..... However, with a manual re-ordering it could take only 1 cycle...8-)) Hope this clarify...... Cya PrZ. -- [<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<] | Codename: PrEdAtOr~Z; Sex: Male; Status: Free coder | * E-mail: predatorzeta(a)geocities.com * | URL: http://www.geocities.com/SiliconValley/Vista/6573 | [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]

2 1

`push' instructions (was: Bug fixes)
by Peter Gerwinski 16 Jun '97

16 Jun '97

According to PredatorZeta: > > Just little clarifying.....:)) > No. Surely not on 80x86 machines. Look this (is for Pentium): > > 1 push (mem) take 2 cycles NOT pairable > > 2 a) mov (mem), reg take 1 cycle pairable > AGI Stall (1 cycle+cut off pairing > system) > b) push reg take 1 cycle pairable > > TOTAL: 3 cycles > > Well, is 2 (not pairable) versus 2 1/2 (not pairable) cycles..... > However, with a manual re-ordering it could take only 1 cycle...8-)) > > Hope this clarify...... Partially. As far as I understand the above, it's push (mem) 2 cycles not pairable mov (mem), reg 1 cycle pariable push reg 1 cycle pairable so both versions have the same speed, but the second one is pairable (-;whatever that means ... I guess it means that it is executed in parallel with a floating point operation, right?). So the second version would be potentially faster, but at least not slower. It seems that I have missed something ... Partially confused, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Encouragement
by Tom Dye 16 Jun '97

16 Jun '97

Hello all, I've been porting VAX Pascal and Borland Pascal code to gpc so that I can compile and run on my Linux box. This has been much easier than I thought it would be--mostly because gpc is an excellent compiler. Keep up the good work! Tom Thomas S. Dye, Ph.D. Home: 813 16th Avenue, Honolulu, Hawaii 96816. Voice (808) 734-2087. Work: International Archaeological Research Institute, Inc., 949 McCully St., Suite 5, Honolulu, Hawaii 96826. Voice (808) 946-2548; Fax 943-0716.

1 0

Re: `Word' data type et al.
by The African Chief 16 Jun '97

16 Jun '97

On Mon, 16 Jun 1997 15:25:56 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >Peter Gerwinski wrote: > >> I noticed a lot of confusion about Integer types in GNU Pascal. [...] >> 32 Integer Word [unsigned] int == long >> 64 LongInt LongWord [unsigned] long long >> >> (BTW: The number of bits is the same on all platforms, isn't it?) [...] > >> I was told more than once that `Word' should have 16 bits (like in >> Borland Pascal). I made it 32 bits because this is the "natural" >> size on a 32-bit system (like GPC), and it has the same size as >> `Integer' (like in Borland Pascal;-). > >I think this is a good idea. However, for BP compatibility one might >define Word as 16 bit in the bpcompat system unit or so, but this should >not be the gpc default, IMHO. In bpcompat's GPCTYPES unit, I have this; {$ifdef _Borland_16_Bit_} Type Single = __short__ Real; Double = Real; Extended = __long__ Real; ShortInt = __byte__ Integer; LongInt = Integer; Comp = __longlong__ Integer; Integer16 = __short__ Integer; Word = __unsigned__ Integer16; {$endif _Borland_16_Bit_} Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Bug fixes (was: "Recursion, need more stack space.")
by Peter Gerwinski 16 Jun '97

16 Jun '97

According to Frank Heckenbach: > > program p; > > var x:record > f:function:real; > end; > > begin > Writeln(x.f) > end. Fixed. > Another little bug I just found: > > program x; > var x:real value 0; {"initial value is of wrong type} > begin > end. Fixed. > Another thing I observed when looking at the asm code (see above) was > that the i386 backend doesn't seem to know the "push mem" instruction. Indeed. > [...] But since it's a backend problem > (the same can happen with gcc), this is probably the wrong place to > report it... Probably. However if you want to try yourself on that problem, look into the GCC info documentation, and read about "machine descriptions". There is something about how to describe each instruction a processor has, and maybe it's a trivial error and somebody overlooked this instruction. Or else: Loading the memory reference into a register and pushing that *might* be faster than a direct push (don't know). Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: "Recursion, need more stack space."
by Frank Heckenbach 16 Jun '97

16 Jun '97

Jan-Jaap van der Heijden wrote: > > Guess what: the program compiled and ran fine with gpc, but couldn't > > possibly compile with BP. :-) > > > :-) :-) Pathetic 64K limits :-) :-) Not because of these, but because BP doesn't handle stacke frames with procedural parameters (variables). If it were only the 64kB limit, that's an old story, I wouldn't even have mentioned it here... > > Another little bug I just found: > > > > program x; > > var x:real value 0; {"initial value is of wrong type} > > begin > > end. > > > It's not a bug, I believe. > > From ISO 10206:1990, sec 6.1.7: > > unsigned-rel = digit-sequence `.' fractional-part [ `e' scale factor ] > | digits-sequence `e' scale factor I thought EP would allow arbitrary expressions as variable initializers (even things like sin(x+3), AFAIR). So an implicit integer->real conversion should be possible, too, I'd think. Even if the standard doesn't demand it, I think it's a good idea to have it in gpc. BTW: Isn't there are general rule like (sorry, I don't know the actual identifiers): real_value = integer_value | ... (IMHO, there should be. After all, as we mathematicians say, $\Z \subseteq \Q$ :-) > I see a simular definition in my Turbo pascal Programmer's Guide, so > BP should not accept it either. I'll look it up, but BP allows some kinds of expressions (e.g. (a+b)/2 if a and b are constants, not with variables, no sin, ...), so it seems logical to allow simple integers, too. > Try to make it "0.0" or "0e0" That's one of the (many) things I don't like about C... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

"Recursion, need more stack space."
by Frank Heckenbach 16 Jun '97

16 Jun '97

First the good news: in c.l.p.b (the same subject as this mail), someone wrote: "Anyway, I found this book in the library called "Programming Languages" by Herbert G.Mayor. In the book it has a program written in Algol-60 by Donald Knuth, which is highly recursive etc.etc, and it was written to separate the 'boy compilers' from the 'man compilers'. The book states, that modern computers are able to run the program with ease." Guess what: the program compiled and ran fine with gpc, but couldn't possibly compile with BP. :-) (It relies on nested stack frames handled correctly with procedural parameters. BP can't do this, but gpc does -- it's not trivial, and it took me some time to understand the asm code generated by gpc... :-) Now the bad news (not really so bad): I then modified the program to compile with BP (quite extensive modifications). The resulting program did not compile with gpc any more. I could trace it down to the following bug (which is actually not related to the problem that the program deals with). gpc doesn't compile the following which is legal in BP (gpc says: "wrong type" in the Writeln): program p; var x:record f:function:real; end; begin Writeln(x.f) end. Another little bug I just found: program x; var x:real value 0; {"initial value is of wrong type} begin end. (Also in other places, automatic integer->real conversion would be nice.) Another thing I observed when looking at the asm code (see above) was that the i386 backend doesn't seem to know the "push mem" instruction. E.g., the program program x; var a:integer value 2; begin writeln(a) end. compiled to asm code for i386-linux, contains the lines movl A.2,%eax pushl %eax where actually pushl A.2 is possible (I tried it, and it worked). But since it's a backend problem (the same can happen with gcc), this is probably the wrong place to report it... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

2 1

Re: Whats wrong?!?
by Frank Heckenbach 15 Jun '97

15 Jun '97

Peter Gerwinski wrote: > > Why is this correct? Isn't Text, being declared as an array of char, > > treated as a 0-terminated string, meaning that the #0 should not be > > printed? > > No. Text being declared as an array of char is treated as a string of > fixed length. The Standard doesn't say anything about 0-termination. > If GPC sometimes takes `chr ( 0 )' as the end of a string, this behaviour > is a remainder of the C back-end and should be reported as a BUG. > (I am not, however, speaking of `CString's (= `PChar's) which are a GNU > (resp. Borland) extension.) Then we have a conflict with BP (the first real one)-: ! The following writes '1.' with BP, and '1[#0]2.' with gpc (regardless of the state of --borland-pascal and --extended-syntax): program x; const a:array[0..3] of char='1'#0'2'#0; begin writeln(a,'.') end. Any ideas how to solve the conflict -- or how to do something equivalent to the BP meaning of this program in gpc at all? Do we need another compiler switch...? And, why is there no #0 output after the '2'? Is this a bug? Ooops, can't gpc write PChars at all? The following doesn't work: program x; {$x+} var a:PChar; begin writeln(a) end. Similarly, the following compiles with BP, but not with gpc: program x; {$x+} var a:PChar; begin a:='Test' {in BP: assign the address of the 0-terminated string 'Test'#0 (stored somewhere statically) to a} end. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

`Word' data type
by Peter Gerwinski 15 Jun '97

15 Jun '97

Hello, everybody! I noticed a lot of confusion about Integer types in GNU Pascal. As I wrote in "info -f gpc -n Integer", these are bits signed unsigned C equivalent 8 ByteInt Byte [unsigned|signed] char 16 ShortInt ShortWord [unsigned] short 32 Integer Word [unsigned] int == long 64 LongInt LongWord [unsigned] long long (BTW: The number of bits is the same on all platforms, isn't it?) I was told more than once that `Word' should have 16 bits (like in Borland Pascal). I made it 32 bits because this is the "natural" size on a 32-bit system (like GPC), and it has the same size as `Integer' (like in Borland Pascal;-). AFAIK, a "word" is defined to be the "natural" unit of the computer, but maybe this definition has changed since I have learned it. If the definition of a word is indeed "16 bits" now, I should change GPC's behaviour. In this case I would appreciate suggestions how to rename all GPC Integer types above (which I wouldn't like to do because I find the above quite consistent). Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: Type casting
by Peter Gerwinski 14 Jun '97

14 Jun '97

According to Orlando Llanes: > > Oh :} Sorry :} I briefly glanced at it, and what I saw was, for example: > > TYPE > ShortInt = __byte__ Integer; > Byte = __unsigned__ ShortInt; > VAR > AVar : Integer; > ASmallVar : Byte; > BEGIN > ASmallVar := BytePtr(AVar)^; > END. > > Something like that... Your program compiles well, if you add `Type BytePtr = ^Byte'. (But it crashes at run-time because you are accessing an uninitialized pointer variable.) > What I meant was type casting using custom types, not with built-in or > pre-defined types. If it already does this, sorry again :} It already does. ;-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
18
Older →

Jump to page:

2025

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 June 1997