Gpc June 1997

gpc@gnu.de

25 participants
172 discussions

Variable type casts
by Frank Heckenbach 19 Jun '97

19 Jun '97

Would it be possible to implement type casts of variables (like in BP) into gpc? Currently, it only seems to know value type casts. What I mean is the following (works in BP): type x=record lo,hi:shortint end; var a:integer; begin with x(a) do begin lo:=10; hi:=1 end; writeln(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

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

19 Jun '97

Maurice Lombardi wrote: > > I'd add {Short,Long,LongLong(?),Longest(?)}{Int,Card} here. > > But this is much harder to standardize: they will have different > meanings on different systems, whence better to reject them in > XXcompat units: gpc being cross-platform it will be difficult to > give a general rule whereas the others are non ambiguous: I didn't intend them to be in a XXcompat unit, but rather built-in (the only place they *could* be declared, AFAICS), provided it can be guaranteed on every platform that - 2 <= SizeOf(ShortInt) < SizeOf(Integer) < SizeOf(LongInt) (or perhaps even 8 <= 4*SizeOf(ShortInt) = 2*SizeOf(Integer) = SizeOf(LongInt) ?) - SizeOf(LongInt) < SizeOf(LongLongInt) (if LongLongInt is possible) (resp. 2*... = ...) - SizeOf(LongestInt) is the biggest possible integer size for the given compiler. (The same, of course, for Card*.) Types like Short* and Long* can be useful e.g. for multplications (ShortInt * ShortInt always fits in an Integer, Integer * Integer fits in a LongInt, ...). Longest* would be useful for programs that want to offer the biggest possible range without having to know what this is on every platform. Furthermore, it *might* become useful to have a Cardinal that's exactly the size of a pointer (since for a normal Cardinal this doesn't always hold, and AFAIK, only the compiler knows the actual pointer size). Though pointer arithmetic has mostly eliminated the need for explicit type casts between pointers and integers, there may be some cases left, where it's needed... > but notice that in BP I frequenly used a defreal unit, > (referenced from the main and all other units) which > contains either > > type real = single > or > type real = double > or > type real = extended > > to have a quick way to see the effect of the size of reals on accuracy > or speed of some computations. But this is a purely private trick > which should be restricted to such peculiar purposes. I think you could do this in gpc as well (I see no reason why not). PS: No copies by email necessary. I get your mails through the list, anyway. Peter Gerwinski wrote: > > > Cardinal 0 .. 2147483647 Non sign=E9, 32 bits > > If Delphi uses "Cardinal", gpc should use it too, of course. > > It already does. 32 bits, unsigned. True, fine! :-) > As you can see above, > `Cardinal' is 31 bits, unsigned, in Delphiy. Has anybody an > idea, why? I guess they didn't want to get into trouble with the internal handling of integer values in the compiler. If Cardinal is a subset of Integer, they can store anything in an Integer internally. Otherwise, they'd have to have a flag indicating if signed or unsigned (I guess this is what gpc does, right?). IOW: The same reason why there wasn't an unsigned 32 bit integer in BP (I suppose). > GPC's current setting - on *all* platforms - is the following: > > GNU Pascal GNU C > > Byte unsigned char > ByteInt signed char Is a char *always* 1 byte in C? > ShortWord unsigned short > ShortInt short > Integer int, long > Word, Cardinal unsigned, unsigned long > LongInt, Comp long long > LongWord unsigned long long How about "ShortCard" and "LongCard", too? I guess, Comp should rather be fixed to 64 bits ("Integer(64)") than dependent on "long long", for BP compatibility. Since you didn't mention it, I assume it's not possible (on current platforms) to have an integer > 64 bits, is it? > I see only one possible reason why we should change that: It is > not absolutely sure that `int' will always remain the same as `long' > on GCC. Is it guaranteed that "short" is always shorter than (resp. half as big as) "int", and "int" than "long long"? > The sizes of these types are the same on all platforms I have seen > so far. (8, 8, 16, 16, 32, 32, 64, 64.) Also on the Alpha? Isn't this a 64 bit processor (so "int" should be 64 bits)? But anyway, I guess, this can change in the future... > I agree, but maybe a different syntax would be preferable. UCSD Pascal > has a "long Integer" type which is written as > > Type Int42 = Integer [ 42 ]; > > Where `42' is the number of decimal digits. (In the long run, this should > be in GPC, too.) What about defining > > Type Int16 = Integer ( 16 ); > Type Word16 = Word ( 64 ); > > for types with a specified number of *dual* digits, read: bits? Why not! (With the actual size rounded up to bytes (or to a power of 2 of bytes) unless in a packed array/record?) > What are we talking about? > > Pascal has subrange types. Why not forget about all this and let the > user specify the types by himself? > > Type > I16 = -$8000..$7FFF; > W16 = 0..$FFFF; > > MyRecordToAccessSomeStrangeSystemData = record > Descriptor: 0..$FFFFFFFF; > ImportantData: -$80..$7F; > FillSpace: array [ 0..42 ] of 0..$FF; > end (* MyRecordToAccessSomeStrangeSystemData *); > > Then, of course, GPC must not reserve more space than necessary for > them - which it does not do anyway since it has packed records. But it does if you declare the type plainly, i.e. Sizeof(0..$FF) = 4. This is handled faster than one byte, but takes more memory. What about "packed" with those types as well ("type Int8 = packed -$80..$7F")? -- Looks strange, I know, but there should be some way to decide if one wants speed or small size (the latter can be important e.g. in binary files). Given this or something equivalent (and of course, subranges that exceed Integer), I'd prefer this to "Integer(n)". The African Chief wrote: > >> {$ifdef _Borland_16_Bit_} > > > >Is this defined by default in your unit? > > No. The definition is commented out (with a dot before the "$") > > > (Otherwise it might be confusing for BP->gpc programmers.) > > BP->GPC programmers (like me) may want BP syntax support, > but not necessarily want to use 16-bit data structures instead > of the default ones. It is quite easy to remove the dot. Ok, so by default the unit uses data types like BP, but it can be changed, right? (That's what I meant how it should be for unsuspicious BP->gpc programmers.) BTW: I just took a look at BPCompat1.0. Just a few quick comments: - How about some sub-directories (perhaps according to the 5 sections of files in *.txt)? Would help in order to see immediately what's needed for "only" BP compatibility, and what's additional functionality. - Concerning FindFirst and FindNext in Dos: is there any reason why they're functions, not procedures? Delphi? If so, perhaps dependent on a compiler switch? (Is there a way to test in a program, if "--borland-pascal" or "--delphi" was given?) Otherwise, you'll always get warnings in BP programs (and I don't think it's a good idea to disable warnings globally). - If you want to use my random functions in System, you're welcome to include them, of course. (Perhaps one day we can claim "100% BP compatibility -- even the random numbers are the same..." ;-). As a preliminary solution for the overloading problem, one could use the (case-sensitive!) preprocessor, as by defining "{$define random RandReal}". Then "random" would be for real types, and all other cases for integers. (Or perhaps vice versa? Or all-caps?) At least, programs could be the same for BP and gpc in this respect. :-) -- 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: `Word' data type et al.
by Frank Heckenbach 19 Jun '97

19 Jun '97

Maurice Lombardi wrote: > You may be interested to know the answer given by Borland to the same > problem in Delphi 2.0 when going from 16 bit to 32 bit system.=20 > The following is a cut out of the Delphi help (in french however): I don't understand much French, sorry, but I think I can recognize the important words :-) > Type Intervalle Format > > Integer -32768 .. 32767 Sign=E9, 16 bits > > Integer -2147483648 .. 2147483647 Sign=E9, 32 bits > > Cardinal 0 .. 65535 Non sign=E9, 16 bits > > Cardinal 0 .. 2147483647 Non sign=E9, 32 bits If I understand it right, Integer and Cardinal have different sizes on 16 and 32 bit Delphi, right? This would be like in gpc (though not 16 bit, AFAIK, but 64 bit and perhaps more). Perhaps contrary to Delphi, I don't think LongInt should be 32 bits on every platform, but rather twice as bug as Integer. What do you think? > The idea is exactly the same as that contained in the letter of > Frank Heckenbach of today, except for the replacement of=20 > Ordinal by Cardinal (which was also suggested by Franck). That's fine! If Delphi uses "Cardinal", gpc should use it too, of course. > So I would vote to implement what is proposed by Franck, > with only the replacement of ordinal by cardinal to have > some compatibility. i.e. > > Generic Types > > Integer Cardinal I'd add {Short,Long,LongLong(?),Longest(?)}{Int,Card} here. > Well defined types > > int8 card8 (=3Dbyte is the only case without doubt) > int16 card16 > int32 card32 > > ... > > card9 =3D 0..2 POW 9 -1 ... if needed: this is always > allowed by the pascal syntax > but the amount of memory involved > is implementation dependant: Sounds good. > Compatibility types > > anything contained in bpcompat.pas delphi1compat.pas > delphi2compat.pas and everything you need, > better than compiler switches when possible to > avoid to garble the compiler by a lot of special > purpose oddities: the idea of C to keep a minimum > in the compiler and a maximum in libraries is > not so bad (when it is possible). I agree! Except for "integer", all types can be redeclared in these units. (I think, "integer" could be redeclared, too, but AFAIR it's not a good idea to do so, is 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: `Word' data type et al.
by Maurice Lombardi 19 Jun '97

19 Jun '97

In message Wed, 18 Jun 1997 20:13:16 +0200 (MET DST), Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> writes: > According to Frank Heckenbach: > >> >> > Cardinal 0 .. 65535 Non sign=E9, 16 bits >> > >> > Cardinal 0 .. 2147483647 Non sign=E9, 32 bits >> >> [...] >> >> That's fine! If Delphi uses "Cardinal", gpc should use it too, >> of course. > > It already does. 32 bits, unsigned. As you can see above, > `Cardinal' is 31 bits, unsigned, in Delphi. Has anybody an > idea, why? > Seems a bug or at least it is inconsistent with the comment that they give to this stuff. Anyway I have checked that Delphi 2 rejects c:=$FFFFFFFF with c cardinal (and gives -1 for c integer); But the idea that we had in mind is that "generic" types are signed (integer) and unsigned (cardinal) integers best suited to a given computer, usually 16 bits Five years ago, 32 bits now, 64 bits in next Five years, 128 bits in next 10 years. This is what is needed for common arithmetic computations. But other needs are e.g. reading binary files coming from other computers or reading I/O ports, where the number of bits has to be specified exactly. >> > Generic Types >> > > GPC's current setting - on *all* platforms - is the following: > > GNU Pascal GNU C > > Byte unsigned char > ByteInt signed char > ShortWord unsigned short > ShortInt short > Integer int, long > Word, Cardinal unsigned, unsigned long > LongInt, Comp long long > LongWord unsigned long long > > I see only one possible reason why we should change that: It is > not absolutely sure that `int' will always remain the same as `long' > on GCC. > > The sizes of these types are the same on all platforms I have seen > so far. (8, 8, 16, 16, 32, 32, 64, 64.) However I agree that it is > a good idea to provide types of known size. > > >> > Well defined types >> > >> > int8 card8 (byte is the only case without doubt) >> > int16 card16 >> > int32 card32 >> > >> > [...] >> >> Sounds good. >> > > I agree, but maybe a different syntax would be preferable. UCSD Pascal > has a "long Integer" type which is written as > > Type Int42 = Integer [ 42 ]; > > Where `42' is the number of decimal digits. (In the long run, this should > be in GPC, too.) What about defining > > Type Int16 = Integer ( 16 ); > Type Word16 = Word ( 64 ); > > for types with a specified number of *dual* digits, read: bits? > Seems fine > > === BUT === > > What are we talking about? > > Pascal has subrange types. Why not forget about all this and let the > user specify the types by himself? > > Type > I16 = -$8000..$7FFF; > W16 = 0..$FFFF; > > MyRecordToAccessSomeStrangeSystemData = record > Descriptor: 0..$FFFFFFFF; > ImportantData: -$80..$7F; > FillSpace: array [ 0..42 ] of 0..$FF; > end (* MyRecordToAccessSomeStrangeSystemData *); > > Then, of course, GPC must not reserve more space than necessary for > them - which it does not do anyway since it has packed records. > (These topics are related, as you can well imagine.) > This is the best Pascalish point of view (and in fact the one I use in computations, if I know that an integer is within 0 and 100, I never declare it as byte but as 0..100, letting the computer determine the amount of space necessary) But for the binary stuff to work it __must__ be granted that the minimum space is actually used: Pascal gives the subrange definition which gives (among others) full compatibility between platforms for computations, but the amount of space which corresponds to a subrange is not enforced. Maurice Lombardi | Laboratoire de Spectrometrie Physique | Maurice.Lombardi(a)ujf-grenoble.fr Universite Joseph Fourier de Grenoble | tel: (33) 04 76 51 47 51 BP 87 | fax: (33) 04 76 51 45 44 38402 Saint Martin d'Heres Cedex FRANCE |

1 0

Re: `Word' data type et al.
by Peter Gerwinski 18 Jun '97

18 Jun '97

According to The African Chief: > > >> 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_} > > I believe that "Byte" is the same in GPC and BP, and so > it doesn't need to be redefined for 16-bit BP. The same is true for `Single', `Double', `Extended', and `Comp'. (Just for compatibility.) 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 Peter Gerwinski 18 Jun '97

18 Jun '97

According to Frank Heckenbach: > > > Cardinal 0 .. 65535 Non sign=E9, 16 bits > > > > Cardinal 0 .. 2147483647 Non sign=E9, 32 bits > > [...] > > That's fine! If Delphi uses "Cardinal", gpc should use it too, > of course. It already does. 32 bits, unsigned. As you can see above, `Cardinal' is 31 bits, unsigned, in Delphiy. Has anybody an idea, why? > > Generic Types GPC's current setting - on *all* platforms - is the following: GNU Pascal GNU C Byte unsigned char ByteInt signed char ShortWord unsigned short ShortInt short Integer int, long Word, Cardinal unsigned, unsigned long LongInt, Comp long long LongWord unsigned long long I see only one possible reason why we should change that: It is not absolutely sure that `int' will always remain the same as `long' on GCC. The sizes of these types are the same on all platforms I have seen so far. (8, 8, 16, 16, 32, 32, 64, 64.) However I agree that it is a good idea to provide types of known size. > > Well defined types > > > > int8 card8 (=3Dbyte is the only case without doubt) > > int16 card16 > > int32 card32 > > > > [...] > > Sounds good. I agree, but maybe a different syntax would be preferable. UCSD Pascal has a "long Integer" type which is written as Type Int42 = Integer [ 42 ]; Where `42' is the number of decimal digits. (In the long run, this should be in GPC, too.) What about defining Type Int16 = Integer ( 16 ); Type Word16 = Word ( 64 ); for types with a specified number of *dual* digits, read: bits? ... === BUT === What are we talking about? Pascal has subrange types. Why not forget about all this and let the user specify the types by himself? Type I16 = -$8000..$7FFF; W16 = 0..$FFFF; MyRecordToAccessSomeStrangeSystemData = record Descriptor: 0..$FFFFFFFF; ImportantData: -$80..$7F; FillSpace: array [ 0..42 ] of 0..$FF; end (* MyRecordToAccessSomeStrangeSystemData *); Then, of course, GPC must not reserve more space than necessary for them - which it does not do anyway since it has packed records. (These topics are related, as you can well imagine.) > > Compatibility types > > > > anything contained in bpcompat.pas delphi1compat.pas > > delphi2compat.pas and everything you need, > > better than compiler switches when possible to > > avoid to garble the compiler by a lot of special > > purpose oddities: the idea of C to keep a minimum > > in the compiler and a maximum in libraries is > > not so bad (when it is possible). > > I agree! Except for "integer", all types can be redeclared in these > units. (I think, "integer" could be redeclared, too, but AFAIR it's > not a good idea to do so, is it?) It's not a good idea for the same reason as it is not a good idea to change the size of `Integer' by a compiler switch. 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: CStrings/PChars
by The African Chief 18 Jun '97

18 Jun '97

On Tue, 17 Jun 1997 16:18:14 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >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. Yes, it does seem so. However, the following program gives different outputs under BP and GPC; program foobar; {$ifdef ver70} Uses Strings; function puts ( astr : PChar ) : char; begin Writeln ( astr ); end; {$else} {$X+} {$W-} function strcopy ( s1 : PChar; s2 : PChar ) : PChar; asmname 'strcpy'; function strcat ( s1 : PChar; s2 : PChar ) : PChar; C; function puts ( s1 : PChar ) : Integer; C; {$endif} function foo ( p : pChar ) : pChar; Begin foo := p + 2; End; Var x : array [ 0..24 ] of Char; Begin strcopy(x, 'African'); strcat(x, #13#10); strcat(x, 'Chief'); puts(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

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

18 Jun '97

On Tue, 17 Jun 1997 16:13:12 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >The African Chief wrote: > >> In bpcompat's GPCTYPES unit, I have this; >> >> {$ifdef _Borland_16_Bit_} > >Is this defined by default in your unit? No. The definition is commented out (with a dot before the "$") > (Otherwise it might be confusing for BP->gpc programmers.) BP->GPC programmers (like me) may want BP syntax support, but not necessarily want to use 16-bit data structures instead of the default ones. It is quite easy to remove the dot. >> 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; I believe that "Byte" is the same in GPC and BP, and so it doesn't need to be redefined for 16-bit BP. 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

Random
by Frank Heckenbach 18 Jun '97

18 Jun '97

I wrote a random unit that uses the same algorithm as BP does. It produces exact the same random numbers as the Random function of BP 7.0 (I heard, older BP versions used a different algorithm, though). Just a couple of notes/questions: - Is the DOS interrupt in Randomize call OK for DJGPP and EMX? I'm not really sure if it's good, but it seems to work. Any improvements welcome! - The code is not meant as a "default" random procedure for gpc, but only for BP compatibility. - Of course, RandReal should have the same name as Random, when function overloading exists. - When range checking exists, NextRand must be compiled without it. (That's why I put "{$W-,R-,W+}" in :-) - The type declarations should be replaced by machine-independent ones (or be predefined by the compiler in the future). - Random produces exact the same random number sequence as BP's integer random. RandReal gives the same values an BP's Random for FPU types (e.g. Double). BP's Random for BP's own Real type differs from that by 0.5 (doesn't really matter, just if someone wants to compare the random values). While writing it, I discovered some type casting bugs in gpc concerning signed/unsigned integers: program x; var a:integer value -$80000000; begin Writeln(ShortWord((LongWord(a)*4) DIV $100000000)); {65534, should be 2} Writeln(Word((LongWord(a)*4) DIV $100000000)); {-2, should be 2} end. Another thing is the implicit real->integer(!) conversion, e.g. "Writeln(Integer(2.2))" works (and gives 2). Is this required by the standard? Otherwise I don't think it should work. At least, it shouldn't with "--borland-pascal". Apropos of BP compatibility: I think many BP users wouldn't like to have to put something like "{$ifdef __gpc__}uses system;{$endif}" in their programs. Is there a way to do this easier? If not, could one be created (perhaps a compiler switch that uses a given unit in all compiled files automatically; though I don't think it should be set by default even with "--borland-pascal", since System is a "contrib". But people could then set an alias to "gpc --automake --executable-file-name --borland-pascal --uses="system" or so...)? --- UNIT Rand; INTERFACE TYPE Cardinal=Word; Card16=ShortWord; Card32=Word; Card64=LongWord; Int32=Integer; VAR RandSeed:Int32 VALUE 0; FUNCTION Random(Range:Card16):Card16; FUNCTION RandReal:Real; PROCEDURE Randomize; IMPLEMENTATION {$W-,R-,W+} PROCEDURE NextRand; BEGIN RandSeed:=$8088405*RandSeed+1 END; FUNCTION Random(Range:Card16):Card16; BEGIN NextRand; Random:=(Card32(RandSeed)*Card64(Range)) DIV $100000000 END; FUNCTION RandReal:Real; BEGIN NextRand; RandReal:=RandSeed/4294967296.0+0.5 END; {$IFDEF __DJGPP__}{$DEFINE DOS}{$ENDIF} {$IFDEF __EMX__}{$DEFINE DOS}{$ENDIF} {$IFDEF DOS} PROCEDURE Randomize; VAR RandSeedLoHi:PACKED RECORD Lo,Hi:Card16 END ABSOLUTE RandSeed; BEGIN ASM("movb $44,%%ah int $0x21" :"=c"(RandSeedLoHi.Lo), "=d"(RandSeedLoHi.Hi) ::"eax","ebx","ecx","edx","esi","edi") END; {$ELSE} FUNCTION Rand:Integer; C; PROCEDURE SRand(Seed:Cardinal); C; FUNCTION GetPID:Integer; C; PROCEDURE Randomize; BEGIN SRand(GetPID); RandSeed:=Rand END; {$ENDIF} 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

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

← Newer
1
2
3
4
5
6
7
8
9
...
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