Gpc March 1997

gpc@gnu.de

17 participants
53 discussions

gpc and gcc 2.7.2.2
by Peter Gerwinski 11 Mar '97

11 Mar '97

According to Stephan Duehr: > I have install gcc and would like to take 2.7.2.2. > I read that gpc 2.0 is for gcc 2.7.2.1. Is it difficult > to make it work with 2.7.2.2? I don't know, but you can do the following: * Some of the GPC source files contain a lot of "#ifdef GPC" constructs. (Mostly gpc-*.c.) Find their GCC source counterparts. * See which of these files have changed from GCC-2.7.2.1 to GCC-2.7.2.2 and apply the changes to the GPC source files. * Compile, and keep your fingers crossed. * Send us a diff with the necessary changes, so we can upgrade GPC from GCC-2.7.2.1 to GCC-2.7.2.2. Please take the most recent (alpha) GPC source. 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 - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Protected parameters, 2nd try
by Berend de Boer 11 Mar '97

11 Mar '97

> Hmmm ... how to tread `protected Var' parameters??? Exactly like const or vice versa (like Borland does: push small bytes on the stack, pass structures as pointers). With protected var the programmer is on his own. Groetjes, Berend.

1 0

Re: Protected parameters, 2nd try
by Berend de Boer 11 Mar '97

11 Mar '97

> would it be necessary that const parameters have > clear semantics concerning side-effects? It doesn't hurt to document them. But the standard already defines protected var as alias dependent, so you should not use that case (it's always a bug, there is no program where this feature is useful or required). I've been hurt by using Borland's const a few times myself (in a case like Peter described). BTW, const and protected var are the same. There is no difference between them. This is mainly a way of saying: this var shouldn't altered (source code as documentation) and speed up it's parameter passing. protected is: this variable shouldn't be altered, even if I make a mistake (by aliasing some things), parameter passing speed is not a problem. Groetjes, Berend.

1 0

varargs in GPC
by Ronald Perrella 11 Mar '97

11 Mar '97

Hi, I thought that GPC did not support varargs. In fact, I was hoping that it would support the VAX Pascal syntax for doing so. What is the status of variable arguments for GPC? -- Ronald Perrella perrella(a)mindspring.com Roswell, Georgia, USA.

1 0

gpc and gcc 2.7.2.2
by Stephan Duehr 11 Mar '97

11 Mar '97

Hi, I have install gcc and would like to take 2.7.2.2. I read that gpc 2.0 is for gcc 2.7.2.1. Is it difficult to make it work with 2.7.2.2? -- Stephan Duehr <Stephan.Duehr(a)FernUni-Hagen.de> ----------------------------------------------

1 0

Variable number of parameters
by Frank Heckenbach 10 Mar '97

10 Mar '97

In news:comp.lang.pascal.borland, there's just a discussion about variable number/types of procedure/function parameters going on. Since Borland Pascal doesn't support this, the discussion has moved quite a bit away from BP towards gpc. That's why I'm forwarding my posting to this list. The complete thread can be seen in the mentioned newsgroup under the same subject as this mail. Perhaps there are some more ideas about this topic in the gpc community, or even some of the things below have been implemented that I don't know about. Certainly, this would rather be a long-time project, and it's not as urgent as removing bugs and implementing some other nice features... Norsk / Hoaxers wrote (in several postings, cut together): > On Tue, 04 Mar 1997 04:46:26 GMT, rdonais(a)southeast.net (R.E.Donais) > wrote: > > >Since Pascal knows the file is a text file, the programmer is not required to > >perform conversions on binary values. In "C", the programmer would at some > >point have to convert the integer to string using something like itoa(). Not explicitly call itoa(), but (s)he'd have to specify the type by a format specifier ("%d") in the format string. This, of course, provides no means of type checking, and is therefore not suited for Pascal. > >I doubt that you want to write separate routines for every combination of > >variables that you plan to write to a text file. Yet, that's what you imply in > >your example. :-\ Yes, I think one has to distnguish overloading from "varargs" (allowing to pass any number and type of parameters). Many useful things can be done with overloading, but Writeln definitely needs varargs, otherwise you'd have to declare an infinite number of Writeln variants. > It was JUST an example. Allow me to give you a better one: > > Load_PcxPicture(s:String;segg,off:Word; > Load_PcxPicture(s:String;segg,off:Word;var Pal:Palettestructure); I don't think it's a good example. In this case, I would pass Pal as a pointer with NIL meaning no palette. Easy to implement and easy to call. I don't think you would write two procedures with similar functionality, so in the end, you'd probably be doing something like this, anyway. But this would be a case for default values as in C++. If you could declare something like procedure LPP(s:String;segg,off:Word;PPal:PPalettestructure value NIL); and call it with wither 3 or 4 parameters (in the former case, the 4th parameter would be implicitly NIL), that would be nice sometimes... (Yet another feature that could be desirable!) > No, i didnt miss it at all, i just found it silly actually. You see, > by implementing "variable syntax" or whatever i should call it, you > dont make it like cobol, basic, fortran or whatever, you -just- make > it more flexible. whats so friggin wrong about that? I really dont > understand whats wrong with it. I don't think there's anything wrong with it, but Borland will not do it. They've dropped TP, face it! So if you want these changes, don't look at TP, but perhaps at GNU Pascal. AFAIK, gpc already supports declaring and calling a procedure with variable arguments, like C - but only to allow calling C functions with varargs. There's not (yet) a way to implement such a procedure in Pascal, but the gpc developers are always looking to enhance the language, so if you've got some concrete ideas (or can even help to work on the compiler), you're always welcome to join the team. > Thats not what I where aiming at. You could make the product better, > and alas get more satisfied customers. That's how the gpc developers/maintainers feel too, I think. > As far as i can remember (this might be wrong) GNU pascal dont have > oop. By now, AFAIK, gpc has (nearly) the same OOP as TP, but doesn't implement the Object Pascal (not-yet-)standard. > >To each his own. If you want overloading and procedures with variable number of > >parameters, then check out languages that support them. > Belive me, I have .. But I really dont like C. Its so.. what should I > say.. pee->(wee&&) .. I just dont like it :) I don't think that's valid in C (provided there's anything that's not valid in C - not sure if there is... :-> ), but I know what you mean. I'd also prefer to have the Pascal syntax and yet many of the other features. > I think that would be a bit to much trouble really. I was just > presenting the idea to get a feeling of other people's thoughts on > the matter. If you're serious about it, join the gpc mailing list. I'll post a copy of this message to the list, since it's quite much about gpc. > Writeln, reset, and a whole bunch of others allready support it. it's > just not any way for the -user- to define procedures like that. > > and that is a shame . :) But of course, it's much more difficult to provide a way for the user to declare and implement such procedures than to just allow some specially handled procedures like Writeln. > >Works great as long as it's blindingly obvious which one is going to be > >called, but consider the following: > > > > Procedure MyProc(C: Char); > > Begin ... End; > > Procedure MyProc(S: String); > > Begin ... End; > > Begin > > MyProc('A'); > > End. > > In that example, you would use the c:char. I guess you would need a > set of rules, but these rules are allready implemented in borland > pascal, since some procedures have this. They have just stopped US > from defining such procedures. That's indeed a problem. The only predefined procedure with this particular ambiguity is (AFAICS) Write[ln], and there it doesn't matter which one is called because the result is the same. That would not be true in general if the user could define the procedures. > I see a couple of -possible- solutions to this. > > One, not very good, would be to require VAR types in function > overloading (thats what you called it, right?), like this: > function f(var nr:byte); > > This would remove the problem all together, but its not a very > flexible way of doing it. Quite restricting... I'm curious for other suggestions. If you have some, just tell us about them. There are problems with ambiguities, and they can be worse than here, as AME demonstrated. One has to find a way to cope with them (or restrict so much that no ambiguities remain). And of course, the rules should be relatively logical and comprehensible and implementable and ... :-) >As a side note: Doesn't FPK support function overloading? > > ?? It does? AME replied: > Either FPK or GNU, I can't remember which. I can't even remember if it > was fully implemented. AFAIK, gpc supports part of the PCSX (Pascal scientific extensions) standard. I don't know this standard, and haven't used these extensions, but I think there is some kind of overloading. You might want to find out if there were any ambiguity problems involved, and how they were solved. > On Wed, 05 Mar 97 07:05:42 GMT, babis(a)hol.gr (Babis Athineos) wrote: > > >Once upon a time a programmer made a tiny little mistake: > >instead of writing procedure Store (var S:TStream); > >he wrote........ procedure Store (var S:PStream); > >Did you see the difference? Store procedures in TV use the stream, > >not the pointer. Pascal compiler would normally find the mistake. > >But Store procedures are not called normally. You pass the address > >of the procedure in a TStreamRec structure and then a TStream.Put > >method calls the Store procedure via the address you passed. No > >type checking! So everything worked OK, except that it didn't save > >right... (I hope I remember correctly the details of the error - > >it's been some years and I don't have the time to try it again...) > > > >Did you get the point? To me the point is that the extensions, however implemented, must still allow Pascal's strong type checking. (In this example, the type checking was annulled by assembler code, type casts or (unnecessarily) untyped pointers, I'd guess from what I know about TV.) > >with variable number and type of parameters, I wouldn't normally > >use it (except maybe in cases like Writeln), but I would consider > >it useful. But if I couldn't choose (e.g. $VT-), I would say it > >is not a Pascal any more... > > I agree fully!! It's a matter of being allowed to chose! Sure. And gpc already has compiler switches to ensure that certain features are [not] used. All the extensions discussed here would be object to these (or additional) switches, too. At last, I've got some suggestions for the varargs problem, too: Apart from overloading (which I'm not talking about now), I'd suggest the following two extensions. Both of them combined would be something like "typed varargs", and allow declaring and implementing Writeln et al.: 1. Unknown number of arguments To the procedure, this would be very much like Open Arrays (cf. TP/BP 7.0). The procedure could get their number with (something like) High, and access them (e.g.) as Parameter[i]. To the caller, however, it's much easier to write than with an Open Array. Anyone who's used these WVSPrintf (or similar) things in TP knows what I mean (declaring an array, assigning the parameters to the elements of the array and then calling the procedure with the array as an argument...) Alternatively, it would suffice to allow "array expressions" like: procedure varnumargs(p:array of integer); begin ... end; var a,b,c:integer; begin varnumargs( (a,b,c,2,c-b,27) ) {^^^^^^^^^^^^^^^^ array declaration as in a "typed const"} end. Ok, one pair of brackets more, but OTOH this allows for more than one open array in the parameter list of a procedure, like: anyproc( (...,...,...),(...,...) ) Probably both ways are useful and have their place... 2. Unknown type of an argument Ok, there are untypes arguments in TP, but they don't allow for any type checking when used, so they're not suited here. Furthermore, the procedure doesn't get any information about the type, so this information would have to be passed separately (as in the printf format string in C), which is not acceptable. So the type must be passed internally, and there must be a way for the procedure to check the type, and to access the parameter as its real type. I could imagine something like the following: procedure Write(Const a); var s:String[255]; begin IFTYPE a,Boolean then if a then WriteStr('True') else WriteStr('False') {^^^^^^^^ this is legal, since a is a Boolean now} else CASETYPE a OF Char: WriteStr(a); {Now a is a Char} String: WriteStr(a); {Here, a is a String - String would include any string type, not just String[255]} LongInt: {Since any integer type in TP can be seen as a subrange of LongInt, this includes all integer types.} begin {In this block, a is an integer} if a<0 then begin WriteStr('-'); a:=-a end; ... end; Real: ...; Extended:...; ... else Error('Cannot write variables of this type!') end end; Note the IFTYPE statement. It would not just check for the type of a, but if successful, cast a into this type for the "then" block. Since the block can only be reached if the type matches, this is type-safe. Similarly the CASETYPE, only for simplified writing. (Of course, the IFTYPE above could be part of the CASETYPE, I just wanted to show both ways.) (This syntax is only tentative, it doesn't have to be called IFTYPE and CASETYPE.) Of course, the SizeOf function would work on a and return the actual size. I pointed to some possible problems with "similar" types (string types, subranges). There will be some problems (e.g. subranges with different sizes, esp. with reference parameters), but I think they can be solved. Of course, it would be nice to elimiate the "else" of the CASETYPE above, and instead cause a compiler error at any attempt to call the procedure with any type not listed in CASETYPE. This would be a behaviour like the real Write. One has to investigate if and how this is possible (considering multiple, possibly nested IFTYPEs/CASETYPEs)... Another idea is whether it is possible and/or useful to compare types of different arguments: procedure equal(const a,b); begin IFTYPE a,b then {Compare SizeOf(a) bytes at @a and @b} else Error('Comparison of different types not allowed!') {^^^ or again, rather a compiler error...} end; It also seems useful to declare local variables of the same type as an argument: procedure swap(var a,b); var temp:TYPEOF(a); begin IFTYPE a,b then begin temp:=a;a:=b;b:=temp end else Error('Swapping different types not allowed!') {see above} end; (I think, Extended Pascal (gpc???) has some kind of type inquiry, but probably only for known types. Anyway, this one could, of course, use the same syntax as EP (it's probably not the syntax above, since I don't know the EP syntax).) Concerning the implementation, I'd say that for each "vartype" parameter an additional (invisible) parameter is passed that describes the type uniquely. Since the compiler has to keep track of all the types somehow anyway, it shouldn't be hard to generate a unique number for each type. The numbers don't have to have any other meaning except being unique, since the IFTYPE/CASETYPE comparisons would be the only things they're used for. Oh, sorry... subranges might have to be considered, but that should also be feasible... The size (for SizeOf) would either be passed as another additional parameter (if used at all in the procedure), or be retrieved through a lookup table via the type number. The varying size of the arguments on the stack (in the case of value parameters) also seems to be a little problem, but I think it can be solved, too. (Perhaps with the help of the SizeOf parameter as far as necessary, or by passing temporary copies by reference...) Type inquiry would be rather easy, since the procedure would only need to know the size of the local variable which can be obtained like the SizeOf above. Many ideas... many problems... much to do... This message is distributed under the terms of the GNU General Public License. The license can be retrieved from many ftp and www sites, e.g. from: ftp://sunsite.unc.edu/pub/gnu/COPYING http://www.mi.uni-erlangen.de/~heckenb/COPYING If you can't get this file, mail me, and I'll send you a copy. -- 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

Some more bugs
by Frank Heckenbach 10 Mar '97

10 Mar '97

Hi everyone! I've got a few more bugs: 1. For loops with chars don't seem to work: PROGRAM p; VAR c:Char; BEGIN c:='A'; {OK} c:='Z'; {OK} FOR c:='A' TO 'Z' DO {"incompatible types in assignment"} END. 2. Under DJGPP, program arguments don't work correctly, as the following program shows. Under Linux it seems to work ok. However, the problem seems to have something to do with Pascal, since gcc programs under DJGPP don't show the problem. {Call the compiled program as "p longparam 2 3" or similar} PROGRAM p; {From info/gpc.i7, slightly modified:} CONST Max_length = 255; { Max length of each argument. If some arg is longer, the run time system traps it. } TYPE Arg_type = String(Max_length); FUNCTION _p_paramcount : Integer; C; FUNCTION _p_paramstr (num: Integer; VAR str: String): Boolean; C; FUNCTION ParamCount: Integer; BEGIN ParamCount := _p_paramcount; END; { ParamCount } FUNCTION ParamStr (arg_num: integer): Arg_type; VAR Str : Arg_type; Success : Boolean; BEGIN Success := _p_paramstr (arg_num, Str); (* Should perhaps do something else on failure. * * Now it returns the empty string, which is also a valid * parameter. *) IF Success THEN ParamStr := Str else ParamStr := ''; END; { ParamStr } {} VAR a:Integer; BEGIN FOR a:=1 TO ParamCount DO Writeln(ParamStr(a)) END. The result is something like: longparam[some other chars] 2ongparam[some other chars] 3ongparam[some other chars] Obviously the length is not set correctly. Frank -- 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: Protected parameters, 2nd try
by Frank Heckenbach 10 Mar '97

10 Mar '97

Peter Gerwinski wrote: > [...] > It needn't be an explicit assignment; it might be a call to a function > which makes the value of `x' change. To pass everything by value *is* > the only possibility. I must admit, I didn't think of these cases. > But I will modify `Const' parameters to pass small things by value and > to work with implicit temporary variables when a constant is passed as > a `Const' parameter. You mean, for big things!? I don't think you need any temporary variables for small things that are passed by value, regardless whether a variable, constant or an evaluated expression is passed. For big things passed by reference, you need a temporary variable if a constant or expression is passed, I think. > Then it's up to the programmer to take care that > the `Const' parameter doesn't change its value due to side effects. Then it would be like Borland's. However, speaking from a purist's point of view, I can see the problem that it would be implementation-dependent whether a parameter is passed by value or by reference. This means it is "undefined" whether side-effects can happen or not. Would it be permissible (well, const parameters aren't standard anyway, I mean in the "spirit" of the standard) to leave that undefined, or would it be necessary that const parameters have clear semantics concerning side-effects? > Hmmm ... how to tread `protected Var' parameters??? As far as I understood it up to now (Berend, correct me if that's not what the standard says), "protected" only means that the compiler must make sure that the parameter isn't altered, and never changes the way of passing the parameter. That would mean: 'const' parameters would be used if the programmer is sure that there can't be any side-effects (which is true in the majority of cases, e.g. if the procedure operates only on local variables and will not be called with the same parameter twice; or e.g. if the procedure reads the value of the parameter only before it writes to any var parameters and/or global variables and/or calls any procedures/functions that do), and wants the compiler to choose the most efficient way of passing and to verify that the programmer doesn't accidentally alter the parameter. 'protected' parameters would be used if there is a danger of side-effects, and the programmer only wants to verify the parameter isn't altered, putting up with a possible inefficiency. (I think it's rare that side-effects become a problem, especially with big structures where the inefficiency would matter.) 'protected var' parameters would be used in the (very rare, IMHO) case that there could be side-effects, and the programmer *wants* these side-effects to influence the parameter. E.g., I could imagine a procedure that watches some variable for changes, but must not change the variable by itself - perhaps in a multi-threaded program where another thread could modify the variable - just fantasizing... -- 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: Protected parameters, 2nd try
by Peter Gerwinski 09 Mar '97

09 Mar '97

According to Berend de Boer: > There is a few cases where it might be a little bit less hard. I think the case > when there are no var parameters (so there is no aliasing) protected should be > protected var. No chance: Var x: Integer; Procedure Bar ( protected y: Integer ); begin (* Bar *) x:= 3; end (* Bar *); ... Bar ( x ); It needn't be an explicit assignment; it might be a call to a function which makes the value of `x' change. To pass everything by value *is* the only possibility. But I will modify `Const' parameters to pass small things by value and to work with implicit temporary variables when a constant is passed as a `Const' parameter. Then it's up to the programmer to take care that the `Const' parameter doesn't change its value due to side effects. Hmmm ... how to tread `protected Var' parameters??? 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 - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Protected parameters, 2nd try
by Berend de Boer 08 Mar '97

08 Mar '97

Oops, sended the msg already. Here again: >> Does that mean that protected (not protected var) parameters >> are passed by value? Especially in the case of large >> structures, can this be inefficient, taking up stack space >> and consuming time to copy the arguments? > Yes. :-( >> Or does the standard prescribe something different? > Yes. It requires that the value of the protected formal > parameter cannot change during the execution of the function, The standard doesn't define it this way. I too think that protected should be treated exactly like var parameters, or whatever is as efficient or more efficient (that's why I use const parameters for in Borland Delphi). The standard says this about protected parameters: peter is essentially correct. (and my initial sentence was incorrect) After a 2nd reading and some trying I don't see a better way to implement it. The compiler would have a really hard job to change protected to protected var when that is allowed. There is a few cases where it might be a little bit less hard. I think the case when there are no var parameters (so there is no aliasing) protected should be protected var. Groetjes, Berend.

1 0

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