Gpc

gpc@gnu.de

5400 discussions

Re: push (was: "Bug fixes")
by Frank Heckenbach 18 Jun '97

18 Jun '97

Jan-Jaap van der Heijden wrote: > The GCC 2.7.2.x backend used by GPC knows nothing about pentium > optimzations or instruction scheduling. I'd think the direct push is also faster on a 386/486, isn't it? (As I said in another mail, I couldn't check it myself.) > [...] So, I guess more work is needed here > (by the GCC crew), although this compiler produces significantly faster > code already :-) Do you know who one could report this problem to, and ask about the backend in general (newsgroups, addresses)? There's another issue (concerning our planned OOP-interface implementation) that I'd like to ask someone about. -- 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

Re: cygwin
by O. Patrick Barnes 18 Jun '97

18 Jun '97

Thanks for the help. That did work nicely. however I still have this problem... I can get winhello.pas to compile, however I get errors in the others when they compile... here is the error: C:\gpcwin32\test\windows>make gpc -g -Wl,-subsystem,windows -o winhello.exe winhello.pas -lkernel32 -lgdi32 -luser32 ld: warning: cannot find entry symbol _WinMainCRTStartup; defaulting to 00401000 gpc -g -o winversion.exe winversion.pas -lkernel32 -lgdi32 -luser32 gpc -g -o compname.exe compname.pas -lkernel32 -lgdi32 -luser32 C:\gpcwin32\test\windows> I captured the make above^^^^^ Also, earlier you asked if I would like to help in the writing of the win32 GUI functions for GPC. I would love to! Just let me know where to start. I am a very good pascal and intermediate C programmer, so my assistance at this is at your disposal. Thanks! -obarnes(a)online.emich.edu > On Mon, 16 Jun 1997, O. Patrick Barnes wrote: > > > Where can I get a copy of GPC with the correct version of cygwin.dll > > included! I can't get the windows version to run! Is there a package > > that includes everything I need, including cygwin?! That would be much > > easier. > > > > ftp://agnes.dida.physik.uni-essen.de/home/janjaap/cygwin32/gpc-i970526.i386-cygwin32-b18.zip > > Hope this helps, > > JanJaap

1 0

Re: Bug fixes (was: "Recursion, need more stack space.")
by Frank Heckenbach 17 Jun '97

17 Jun '97

Peter Gerwinski wrote: > Fixed. :-) > 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. > > [...] > > 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. I looked at i386.h and i386.md, and it seems like there isn't even a way to push anything but registers and constants... ?-( > Or else: Loading the memory reference into a register and > pushing that *might* be faster than a direct push (don't know). That might be a reason. But I don't know, either. I would suppose not -- why should the extra loading a register be faster? I tried some ways to measure the actual time (system clock, ps, /proc/..., even gprof), but they were all terribly inaccurate (+/- 5..10%), so there's no chance to check which is faster. :-( Anyone knows a way to measure runtime presicsely (Linux or DJGPP)? Jan-Jaap van der Heijden wrote: > unsigned-rel = digit-sequence `.' fractional-part [ `e' scale factor ] > | digits-sequence `e' scale factor > [...] > I see a simular definition in my Turbo pascal Programmer's Guide, so > BP should not accept it either. The BP handbook says (Fig. 2.3, at least in the German version): unsigned real value (as above) unsigned numerical value = unsigned integer | unsigned real value This looks reasonable to me. -- 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

CStrings/PChars
by Peter Gerwinski 17 Jun '97

17 Jun '97

According to The African Chief: > > Great! Now one last thing about pChars - can you make > them type-compatible with zero-based arrays of Char? It seems to work already ... my GPC just compiled: program foobar; {$X+} function foo ( p : pChar ) : pChar; Begin foo := succ ( p, 2 ); End; Var x : array [ 0..4 ] of Char value 'xyOK'#0; Begin writeln ( foo ( x ) ); End. (Note that the (*$X+*) directive is needed to enable both pointer arithmetics and `pChar's being treated as Strings.) 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: `Word' data type et al.
by Frank Heckenbach 17 Jun '97

17 Jun '97

The African Chief wrote: > In bpcompat's GPCTYPES unit, I have this; > > {$ifdef _Borland_16_Bit_} Is this defined by default in your unit? (Otherwise it might be confusing for BP->gpc programmers.) > 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_} Don't forget: Byte = __unsigned__ Shortint; But I think you could use the "more comfortable" gpc identifiers now, just to make it a bit more readable. -- 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

CStrings/PChars (was: Whats wrong?!?)
by Peter Gerwinski 17 Jun '97

17 Jun '97

According to The African Chief: > > Great! Now one last thing about pChars - can you make > them type-compatible with zero-based arrays of Char? > This is the case with BP - so that any function/procedure > that takes a pChar as a parameter will accept a zero-based > array of Char as well - thanks! Thanks for the example programs! They make it easier to implement. I must admit that I do not really like this CString/PChar stuff: All this is C, not Pascal, and I am implementing it for compatibility's sake only - both with Borland compilers and with C libraries which exist on many platforms and are important to support. However, this will only work in GPC together with the (*X+*) directive. 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: `push' instructions (was: Bug fixes)
by PredatorZeta 17 Jun '97

17 Jun '97

According to Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de>: > 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 ... Only theoretically..::)) This is because between the two instructions there is an AGI stall, a Pentium hardware-generated LOCK instruction.(why? because there is a read after write!!) 8-< This block ALL pairing rules and costs 1 cycle. Then: 1 cycle for the MOV pairable (BUT THAT DON'T PAIR!!) 1 cycle for AGI (block all pipeline!!) 1 cycle for the PUSH pairable = 2 cycles(not pairable) + 1 pairable= 2 1/2 cycles > I guess it means that > it is executed in parallel with a floating point operation, > right?). Yez, but also PUSH (MEM) can do this... Cya PrZ -- [<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<] | Codename: PrEdAtOr~Z; Sex: Male; Status: Free coder | * E-mail: predatorzeta(a)geocities.com * | URL: http://www.geocities.com/SiliconValley/Vista/6573 | [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]

1 0

Re: Whats wrong?!?
by The African Chief 17 Jun '97

17 Jun '97

On Tue, 17 Jun 1997 02:11:17 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >According to Frank Heckenbach: >> >> Ooops, can't gpc write PChars at all? The following doesn't work: >> >> program x; >> {$x+} >> var a:PChar; >> begin >> writeln(a) >> end. > >Fixed. > >> 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. > >Fixed. Great! Now one last thing about pChars - can you make them type-compatible with zero-based arrays of Char? This is the case with BP - so that any function/procedure that takes a pChar as a parameter will accept a zero-based array of Char as well - thanks! e.g., program foobar; uses strings; {$W-} function foo ( p : pChar ) : pChar; Begin writeln ( p ); foo := strlen ( p ); End; Var x : array [ 0..64 ] of Char; Begin strcopy ( x, 'Dr. Chief' ); writeln ( foo ( x ) ); End. 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

Help!
by O. Patrick Barnes 17 Jun '97

17 Jun '97

Where can I get a copy of GPC with the correct version of cygwin.dll included! I can't get the windows version to run! Is there a package that includes everything I need, including cygwin?! That would be much easier. Thanks, obarnes(a)online.emich.edu

2 1

Re: `Word' data type et al.
by Frank Heckenbach 17 Jun '97

17 Jun '97

Peter Gerwinski wrote: > I noticed a lot of confusion about Integer types in GNU Pascal. So did I (read: I was confused in the beginning ;-). I was going to post something about it sometime anyway... > 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?) Even if it is now, it probably won't be forever, I guess... (What about the 64 bit platforms (Alpha)? Isn't Integer 64 bits there? Should it be? What about LongInt there?) Is it always (on every platform) guaranteed that "Integer" is strictly bigger than "ShortInt", and "LongInt" is strictly bigger than "Integer"? BTW: Is 64 bits the biggest possible size (at least for 32 bit platforms), or would it be possible to make 128 bit types? (If not, this would probably decide how big the ClassID for objects will be, BTW...) If so, it might probably be called "LongLongInt", and then I'd also suggest something like "LongestInt" or so to get the actually biggest possible type on every system. > 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. Christian Wendt wrote: > It could be depend on the Compilerswitches? (there's a --borland-pascal > switch?) > [...] > advantage: BP programms can be compiled more identically. > (maybe someone uses specific type to swap sign by adding.... %-) Argh! But there are cases where the size is necessary (e.g. data files that should be read). I'd favour an explicit declaration instead of this compiler switch, because in many places, even in BP programs, you don't necessarily want the BP sizes (e.g. one often uses "Integer" without much thinking about the exact size, just to have "an integer data type", so it wouldn't hurt to use gpc's 32 bit integer instead). For a quick BP->gpc conversion, one could use the BP identifiers declared in system. Then, to improve the program, one could find those places where the size really matters, and put types like int8 (8 bit integer) or such there. Those can be declared with gpc and BP. Peter Gerwinski wrote: > AFAIK, a "word" is defined to be the "natural" unit of the computer, > but maybe this definition has changed since I have learned it. I think this is correct. However, the word "Word" seems inappropriate to me. In natural language, this word has a different meaning (as this sentence shows), and in mathematics and computer science it has usually also another meaning (a finite sequence of elements of a given "alphabet"). I think "Word" in this sense is only common in assembler, and crept into Pascal through BP (correct me if I'm wrong). So, what else? In mathematics, one says "natural numbers", but I don't think "natural" would be a natural name for this data type... ;-). "unsigned integer" as in C doesn't seem so good, either, simply because it's two words. What about a name as "ordinal" (or "cardinal" -- which one would be better?)? In the following I'll write "ordinal", and in analogy to "LongInt" and "ShortInt" also "LongOrd" and "ShortOrd". (The similarity in name to the Ord function is, of course, not accidental, since ord(x) will always be "ordinal", except if x is a signed integer, or one of the "strange" enum values we discussed recently.) To me, such a name would seem more "high level" (Pascalish) than "word" (low level, assembler) or "unsigned" (medium level, C). > It would not be difficult to implement a compiler switch (*$16-bit *) (or > a command-line option `--16-bit') to make `Integer' and `Word' 16 bits etc., > but I am not so sure that this is a good idea since GPC is a true 32-bit > compiler. If we want to look out for a different "natural" data size for > GPC, it should not be 16 bits, but 64 bits! I don't think such a switch would be a good idea, or even necessary. If someone wants Word to be 16 bits, one can just redeclare it (e.g. in system) -- after all, "Word" is not a reserved word... Orlando Llanes wrote: > I have an idea, perhaps there could be platform dependant types, for > example: VAR MyVar : PCByte; This way it would be treated as 8-bits on all > platforms, the natural types can stay, all one has to do is use the > platform type to compensate for it if necessary. This way, 1) the data > works consistently across all platforms because (for example) they know > that a PCByte is 8 bits, 2) If a byte is a different size on another > platform, then it doesn't matter because the PCByte is the same no matter > where it's compiled. I guess this could be accomplished by making the > PCByte a natural Byte, but in the code, anything above the 8 bits is not > used. I agree (I also don't like things like "__byte__ integer", because it reminds me of C ;-), and I find such identifiers with many underscores "ugly" -- IMHO, if they're necessary at all, they should be there only in a few low level modules/units). But I wouldn't like the name "PCByte". I don't think "PCByte" will be easy to remember... What about the following (the meanings are obvious): Int8 Ord8 Int16 Ord16 Int32 Ord32 Int64 Ord64 Int128 Ord128 (?) [...] If subrange types would automatically have the correct size (currently they don't -- unless within a packed array or record), and "subranges" are also allowed for ranges that exceed integer (like "Ordinal" or "LongInt"), one could just declare all of these types in a normal way like "Int8=-$80..$7F" ... "Ord128=0..$FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF". :-) For BP->gpc, as I said above, the types to choose depend on what's really intended. I think one could use about the following rules (please check them carefully; I made several assumptions about the types of which I'm not sure they're valid on all platforms): BP: ShortInt gpc: Int8 BP: Byte gpc: Ord8 BP: Integer gpc: - If exactly a "16 bit signed integer" is wanted, Int16 - If an integer of at least 16 bits is wanted, ShortInt - If just "an integer" is wanted (maybe implying that it can be handled most efficiently), Integer BP: Word gpc: - If exactly a "16 bit unsigned integer" is wanted, Ord16 - If an unsigned integer of at least 16 bits is wanted, ShortOrd - If just "an unsigned integer" is wanted (maybe implying that it can be handled most efficiently), Ordinal - If the biggest possible unsigned integer is wanted (though this might be rare, since one would probably rather use LongInt then in BP though that's signed), LongOrd BP: LongInt gpc: - If exactly a "32 bit signed integer" is wanted, Int32 - If an integer of at least 32 bits is wanted, Integer - If an integer type is wanted that's bigger than Integer (e.g. to hold the result of a multiplication of two integers), LongInt - If the biggest possible [signed] integer type is wanted, LongInt (LongLongInt? LongestInt?) - If an unsigned (!) integer of at least 31 bits is wanted, Ordinal - If the biggest possible unsigned (!) integer is wanted, LongOrd (Did I miss any possible intentions? ;-) Another thing, only partly related to the above: is there any support for endianness (i.e. byte order of integers that are bigger than 1 byte) in gpc yet? (This would be necessary e.g. to read binary files on different platforms.) If not, I'd suggest funtions like "SmallEndian" and "BigEndian", defined for all integer types, which convert a value, given in the normal machine's endianness, to a small endian or big endian value, resp. (or vice versa, which is the same conversion). On each given platform, one half of the functions would do nothing, the other half would reverse the byte order. If there's a conditional define concerning endianness, such functions could be implemented in Pascal with {$IFDEF}'s, otherwise they'd have to be provided by the compiler. Next topic:-) While we are talking about integer sizes, what about boolean sizes? Usually, a boolean is 1 bit, of course, but in some cases (e.g. system calls) one needs booleans of 1 byte (this would only be a difference in a packed array or record) or 2 bytes (e.g. Windoze API, cf. BP's "bool" type), perhaps even more. So it might be useful to have "bool8", "bool16", ... . The internal value 0 would be false, and any other value would be interpreted as true, while the standard true value is 1 (or -1?). Syntactically they would be treated just like booleans (i.e. assignment compatibility between each other, but not with integers; can be used in if/while/until conditions; work with and/or/xor/not/...). And one more topic (also related to some kind of sub-types, at least): Dr John Stockton <jrs(a)merlyn.demon.co.uk> wrote once in c.l.p.b.: > A better language might include sub-types of real, > R>0 R>=0 R<0 R<=0 R<>0 , > with rangechecking. ...or, more generally, arbitrary intervals. Or even more generally, sub-types with a user-defined function(super_type):boolean to decide if an element belongs to the sub-type. (Of course, subranges of ordinal types are a special case of this, too, at least in theory...) Since all of this would only affect range checking, it's not a current topic for now. With range checking, it might not even be very difficult to implement, just using the user-defined function instead of the "standard" range checking function... BTW: Does the PXSC standard have any ideas about such things? -- 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

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