Gpc June 1997

gpc@gnu.de

25 participants
172 discussions

Bug with text files
by Frank Heckenbach 20 Jun '97

20 Jun '97

The following works as a program, but not as a unit (used e.g. by an empty program). It gives the following runtime message (DJGPP and Linux): ?GPC runtime error: (gpc-rts) _p_initfdr() has not been called for file (#701) {$define u} {$IFDEF u} UNIT printer; INTERFACE {$ENDIF} USES System; VAR Lst:Text; {$IFDEF u} IMPLEMENTATION TO BEGIN DO {$ENDIF} BEGIN Assign(Lst,'LPR'); Rewrite(Lst); writeln(Lst,'Test'); Close(Lst) {$IFDEF u} END; {$ENDIF} END. Apropos: Did anyone write a portable printer unit yet? -- 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 types...
by Peter Gerwinski 20 Jun '97

20 Jun '97

According to Orlando Llanes: > > The only reason I suggested having Platform specific types is because > since the size varies per system, and you save a file using natural types > on one, they have to be read in using the same size. For example, let's say > a Word is 32-bit on one system, and then you have the PC where it's 16-bit, > let's call them Word (32-bit) and PCWord (16-bit). The natural size of a Word on the PC equipped with a 80386 or higher is 32-bit. The restriction of most applications to 16 bits is an artificial one and orginates to Microsoft which did not react on the hardware improvement. We do. > Word is 4 bytes, PCWord is 2 bytes. If data was written using PCWord, it > could be read into a Word. But if a Word was written, then it needs 2 > PCWords to read it properly. In this way, it's not cross platform because > you have to make adjustments per platform. So what you are really worrying about is the binary format (which includes the size) of these types, not the platform where they are "natural". I agree. This means that the following is the way to go: > I'm all for the IntX data types > suggested earlier for this reason, if one data type is treated the same > across all platforms, then all you have to do is write a program once, and > then compile it across all platforms without having to use platform > specific compiler options. [...] So it's clear what has to be implemented. Now we must discuss about their syntax. Where do such data types matter? Everywhere where we must set up a record type of well-known size and structure, for example when reading a binary file created by some other program, or when communicating with the operating system. For this reason, the syntax must be compact, and somehow closer to the bare metal (assembler) than to the clouds (Modula). That's why I prefer `Word' here with respect to `Cardinal'. (* Another reason is that when I read `Card', I think of games, not of cardinalship. ;*) (Due to the need for compactness, I think my "Integer ( 8 )" notation was not the best idea. Or perhaps it was, and the programmer can define the below in his own Units?) So what about this? Int8 Word8 = Byte Int16 Word16 Int32 Word32 Int64 Word64 Once more discussing subranges as an alternative: "True Pascal" does not specify the storage size, but valid values for those. So I am no more sure whether it is wise to guarantee that their size will always be the minimal one. And anyway, they are no true replacement for built-in data types of well-defined size because no programmer will write `0..$FF' everytime he wants to express that something has 8 bits. He will define his own type for this reason: "Type Byte = 0..$FF". (Note that `Byte' is built-in in GPC!) If we don't want terrible confusion among future GPC hackers, we should provide built-in types for such purposes. The other thing we must worry about is compatibility to GNU C, because the use of GNU Pascal depends on library written in GNU C. For this reason, `ShortInt', `ShortWord', `ByteInt', and `Byte' must stay like they are; I think it's quite natural then to have `Word' for an unsigned 32-bit Integer. I am not sure whether `int' in GNU C might ever change to be different from `long int'. (DOES SOMEBODY KNOW???) If so, our (my;) choice for the meaning of `LongInt' and `LongWord' might be subject to change. (Note again that I am speaking about types that *are* built-in in GPC with the mentioned meanings.) 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: system.pas
by Peter Gerwinski 20 Jun '97

20 Jun '97

According to Frank Heckenbach: > According to The African Chief: > > According to Frank Heckenbach: > > > > > > (Is there a way to test in a program, if "--borland-pascal" or > > > "--delphi" was given?) > > > > I know of none. > > If there isn't, could you make one, Peter? (Perhaps just some > predefined symbols?) What about `__BORLAND_PASCAL__' and `__DELPHI__' (and `__EXTENDED_PASCAL__' and `__STANDARD_PASCAL__' etc. which are of course useless because these dialects don't allow conditional defines anyway;-)? > > True enough. In BP, when {$X+} is used, you can use functions just > > like procedures. Perhaps Peter can add this to GPC as well, so that > > no warning is generated in such instances? If this happens, then we > > don't need to turn off warnings. This was one of the very first things I did to GPC. It was in version 1.1-turbo-alpha-1.0, aka turbo-gpc-2.6.3.tar.gz, aka turbo11b.zip. Everybody, PLEASE check what GPC can already do and what it cannot BEFORE you post to this list. You are confusing possible GPC newcomers! ;-) > Perhaps (additionally) a separate switch for those who want to use > functions as procedures, but without the "risks" implied by "{$X+}" > in other aspects? I guess, most of my units would use such a switch. Ignoring a function's return value *is* a risky thing, because it switches off an error-checking rule which is important for teaching. Programmers who want to use this feature usually (should;-) know what they are doing, and won't be hit by the other "risky" things. For instance: A beginner might unintentionally increment a pointer instead of the value pointed to. An expert probably won't - he produces much uglier bugs. > So I'm asking the asm experts here: I am not an asm expert, but here are my guesses. > - First, the asm syntax -- can it change, or will it always work like that? It won't change. To much GCC stuff depends on the asm syntax as it is now, and GPC will stay compatible to GCC. Maybe, somebody will implement an alternative Borland-compatible asm syntax, but this will be an extension. (And, since I now know the advantages of GPC's asm syntax, I won't even vote for doing that.) > - Could using 8 and 16 bit registers ever be a problem (note: that's only > for __DJGPP__ and __EMX__)? No. (Note: That's only for iX86-platforms.) > - Is calling the Dos interrupt like I did it ok, or is there a better way > (perhaps some DPMI calls Praxis has shown for me that interrupts which don't pass pointers work without any DPMI magic. But take care of clobbered registers! > -- perhaps even without any asm, that would be better). No. This would be *very* system-dependent, so it should not be a GPC built-in. > > > As a preliminary solution for the overloading problem, one could use > The only way to do it (AFAICS) are include files, or defines on the command > line. (BTW: does "-Drandom=RandReal" or such work, or could it be made to > work?) It does work. > Would it seem reasonable (and feasible) to propagate defines > (either all of them, or only those that are specially marked) through > .gpi files? No. Defines are C. We do Pascal. However, it would be desireable to allow inline functions transported through GPI files which have the same functionality (including translating C macros) but are *much* cleaner. To achieve this, somebody would have to extend my `store_tree()' (in `gpc-module.c') to store function bodies in GPI files, too. 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: Variable type casts
by Peter Gerwinski 20 Jun '97

20 Jun '97

According to Frank Heckenbach: > > > Would it be possible to implement type casts of variables (like > in BP) into gpc? Currently, it only seems to know value type casts. It knows variable type casts, but only of "simple" types. I will see what I can do. 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

Bug with string(x)
by Frank Heckenbach 20 Jun '97

20 Jun '97

In the following program, the capacity is not handled correctly. x contains the full alphabet (though it shouldn't), and y contains garbage (at least on Linux, not on DJGPP). var y,x:string(10); begin y:=''; x:='abcdefghijklmnopqrstuvwxyz'; writeln(x); writeln(y) 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: system.pas
by Frank Heckenbach 20 Jun '97

20 Jun '97

The African Chief wrote: > No. SYSTEM.INC (which is $INCLUDEd into GPCTYPES.PAS) > contains this; > > {.$DEFINE _Borland_16_Bit_} { 16-bit Borland data types } > {$DEFINE _Borland_Pascal_} { Borland string types } Ah, now I understand! Looks reasonable to me. > Yes, it is giving me problems with certain things in the cygwin32 C > headers. It would have made things a lot easier if they could be > exported in units - but you can't have everything ! ;-) Why not? This is gpc! ;-) > >The only way to do it (AFAICS) are include files, or defines on the command > >line. (BTW: does "-Drandom=RandReal" or such work, or could it be made to > >work?) > > I am not sure. I just tested it, it seems to work already! > That would make my life a lot easier with translating C macros to > Pascal. However, it may be of dubious long-term benefif. At the > moment, I have to translate all those C macros into Pascal > functions. This is bit tedious, but it is probably better in the > long run. Who knows? I think it's better to translate them to functions wherever possible, though it is tedious. But there may be some things left that can't be translated adequateley -- overloaded functions are one such thing (perhaps some day they will be possible in gpc, too), and there may be other things... On a somewhat similar but different topic: Perhaps the state of some compiler switches that influence the generated code (e.g. range and stack checks when they're implemented; probably not optimization) and all the defines that are active at the beginning aof the compilation of a unit could be stored in the .gpi file. When the unit is used, and automake is active, the compiler could check if the current settings match those stored in the .gpi file, and if not, have the unit recompiled. So, if one wants to change one switch (e.g. the _Borland_16_Bit_ above), one could still use the automake and have all units updated if necessary. (In the case of defines, this would also require to store in the .gpi file which defines are tested or used, so that changing an unrelated define will not cause to unit to be recompiled.) And how about something like "--autobuild" to compile all units whether or not this seems necessary? This could be useful for a final compilation of a project (probably with a highest optimization), or to recompile something for a different platform in the same directory without having to manually remove all the .{o,gp[mi]} files (this happens to me often with DJGPP and Linux). -- 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 types...
by Orlando Llanes 19 Jun '97

19 Jun '97

The only reason I suggested having Platform specific types is because since the size varies per system, and you save a file using natural types on one, they have to be read in using the same size. For example, let's say a Word is 32-bit on one system, and then you have the PC where it's 16-bit, let's call them Word (32-bit) and PCWord (16-bit). Word is 4 bytes, PCWord is 2 bytes. If data was written using PCWord, it could be read into a Word. But if a Word was written, then it needs 2 PCWords to read it properly. In this way, it's not cross platform because you have to make adjustments per platform. I'm all for the IntX data types suggested earlier for this reason, if one data type is treated the same across all platforms, then all you have to do is write a program once, and then compile it across all platforms without having to use platform specific compiler options. I'm not suggesting that they truly have to be 16-bit or 8-bit, just that to the programmer and the program they are, to GPC they can be 32-bit. I'm suggesting those data types as a supplement, not as a replacement. Ok, it may be hard to remember (for some, but I for one could remember them), but beginners don't have to worry about it, and when they advance, it's there for them to use as they see fit. See ya! Orlando Llanes

1 0

Re: system.pas
by The African Chief 19 Jun '97

19 Jun '97

On Thu, 19 Jun 1997 15:36:20 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >The African Chief wrote: > >> I am not sure I understand what you mean. However, the idea is >> this. GPC is a 32-bit compiler that wants to support the BP syntax; >> so we try to do support the *syntax* - thereby helping BP folks to >> move their programs to 32-bit.; so we keep the data structures in >> their 32-bit format - but, if, for some reason, a person who wants >> to move his 16-bit programs to 32-bit with GPC still wants his >> data types to be exactly as they are in a 16-bit compiler, then he >> has to remove a dot on one line in the unit wherein the data types >> are defined, and recompile his program. > >Yes, I see the problem. So your defaults are to use the bigger types. >I don't think that's a problem for most programs (though I just saw >one that wanted to write a LongInt, and gpc can't yet write 64 bit >variables -- but, of course, it would make more sense to implement >this feature into the RTL than to restrict the size for that reason :-). Agreed :-)= >I'm not sure I really understood how your declaration looks like. Is it >the following: > >{.$ifdef borland-16-bit} No. SYSTEM.INC (which is $INCLUDEd into GPCTYPES.PAS) contains this; {.$DEFINE _Borland_16_Bit_} { 16-bit Borland data types } {$DEFINE _Borland_Pascal_} { Borland string types } {$ifdef _Borland_16_Bit_} {$DEFINE _Borland_Pascal_} {$endif _Borland_16_Bit_} [...] >> The problem with $define is that it does not export from units. Will >> this be a problem? > >Yes! :-( Yes, it is giving me problems with certain things in the cygwin32 C headers. It would have made things a lot easier if they could be exported in units - but you can't have everything ! ;-) >The only way to do it (AFAICS) are include files, or defines on the command >line. (BTW: does "-Drandom=RandReal" or such work, or could it be made to >work?) I am not sure. >Would it seem reasonable (and feasible) to propagate defines >(either all of them, or only those that are specially marked) through >.gpi files? At first sight, I'd think so. That would make my life a lot easier with translating C macros to Pascal. However, it may be of dubious long-term benefif. At the moment, I have to translate all those C macros into Pascal functions. This is bit tedious, but it is probably better in the long run. Who knows? 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: system.pas
by Frank Heckenbach 19 Jun '97

19 Jun '97

The African Chief wrote: > I am not sure I understand what you mean. However, the idea is > this. GPC is a 32-bit compiler that wants to support the BP syntax; > so we try to do support the *syntax* - thereby helping BP folks to > move their programs to 32-bit.; so we keep the data structures in > their 32-bit format - but, if, for some reason, a person who wants > to move his 16-bit programs to 32-bit with GPC still wants his > data types to be exactly as they are in a 16-bit compiler, then he > has to remove a dot on one line in the unit wherein the data types > are defined, and recompile his program. Yes, I see the problem. So your defaults are to use the bigger types. I don't think that's a problem for most programs (though I just saw one that wanted to write a LongInt, and gpc can't yet write 64 bit variables -- but, of course, it would make more sense to implement this feature into the RTL than to restrict the size for that reason :-). I'm not sure I really understood how your declaration looks like. Is it the following: {.$ifdef borland-16-bit} In this case, one would have to remove the dot, and to define "borland-16-bit", wouldn't one? I think you can just remove the dot always. Then programs compiled without "borland-16-bit" would still use the long types, and the short types if compiled with that define (which can be put into the source if one wants to use it always, or given on the command line ("-Dborland-16-bit") for one-time use). > > (Is there a way to test in a program, if "--borland-pascal" or > > "--delphi" was given?) > > I know of none. If there isn't, could you make one, Peter? (Perhaps just some predefined symbols?) > True enough. In BP, when {$X+} is used, you can use functions just > like procedures. Perhaps Peter can add this to GPC as well, so that > no warning is generated in such instances? If this happens, then we > don't need to turn off warnings. Perhaps (additionally) a separate switch for those who want to use functions as procedures, but without the "risks" implied by "{$X+}" in other aspects? I guess, most of my units would use such a switch. > >- 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..." ;-). > > Okay, thanks. I will see if I can add it. AFAICR your unit uses some ASM > statements. Are we sure that ASM code in GPC will stand the test of time? I'm not ;-( So I'm asking the asm experts here: - First, the asm syntax -- can it change, or will it always work like that? - Could using 8 and 16 bit registers ever be a problem (note: that's only for __DJGPP__ and __EMX__)? - Is calling the Dos interrupt like I did it ok, or is there a better way (perhaps some DPMI calls -- perhaps even without any asm, that would be better). If so, could someone please provide the code to do so? > > 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. :-) > > The problem with $define is that it does not export from units. Will > this be a problem? Yes! :-( The only way to do it (AFAICS) are include files, or defines on the command line. (BTW: does "-Drandom=RandReal" or such work, or could it be made to work?) Would it seem reasonable (and feasible) to propagate defines (either all of them, or only those that are specially marked) through .gpi files? At first sight, I'd think so. -- 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

system.pas (Was `Word' data type et al)
by The African Chief 19 Jun '97

19 Jun '97

On Thu, 19 Jun 1997 03:22:55 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: [...] >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? I am not sure I understand what you mean. However, the idea is this. GPC is a 32-bit compiler that wants to support the BP syntax; so we try to do support the *syntax* - thereby helping BP folks to move their programs to 32-bit.; so we keep the data structures in their 32-bit format - but, if, for some reason, a person who wants to move his 16-bit programs to 32-bit with GPC still wants his data types to be exactly as they are in a 16-bit compiler, then he has to remove a dot on one line in the unit wherein the data types are defined, and recompile his program. >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. Yes, that will happen in the next release. >- Concerning FindFirst and FindNext in Dos: is there any reason why > they're functions, not procedures? > Delphi? Yes. > If so, perhaps dependent on a compiler switch? At present, no. > (Is there a way to test in a program, if "--borland-pascal" or > "--delphi" was given?) I know of none. > Otherwise, you'll always > get warnings in BP programs (and I don't think it's a good idea to > disable warnings globally). True enough. In BP, when {$X+} is used, you can use functions just like procedures. Perhaps Peter can add this to GPC as well, so that no warning is generated in such instances? If this happens, then we don't need to turn off warnings. >- 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..." ;-). Okay, thanks. I will see if I can add it. AFAICR your unit uses some ASM statements. Are we sure that ASM code in GPC will stand the test of time? (I have some programs which use a lot of 8086 asm code, and it is impossible to port these to Delphi 2 ...). > 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. :-) The problem with $define is that it does not export from units. Will this be a problem? 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

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