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 … [View More]

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 … [View More]

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 … [View More]

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 … [View More]

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; > {$… [View More]

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 … [View More]

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 … [View More]

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+} >> … [View More]

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 … [View More]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 [View Less]

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