Gpc

gpc@gnu.de

5400 discussions

Re: bugs, incompatibity, function attributes
by The African Chief 01 Jul '97

01 Jul '97

On Tue, 1 Jul 1997 01:15:36 +0100 (WET DST) Jan-Jaap van der Heijden <janjaap(a)Wit381304.student.utwente.nl> wrote: [...] >So: > >1. Are there any reasons not to change the "external" declaration, at > least for "borland" mode? 1. specifying DLL names; With Borland, you need to specify the name of the DLL from which you are importing a function. You need to do this with *every* function. This is extremely tedious. Try doing that with the whole Win32 API for example. Also, you would need to find some documentation on which DLL holds which function. That is even more tedious. Thus, if we are going to support the Borland syntax, then using it should be optional. With GPC, you don't need to specify the DLL name - that is, I think, a *great* advantage over Borland. 2. not having to redeclare the entire function in the implementation section; I think it is good to support this. With Borland, you can redeclare the whole function, or you can just specify it's name. You are not forced to do it in any particular way, and you can mix and match. It would be nice if GPC supported this. 3. Delphi's "name" directive; This is exactly the same as GPC's "asmname" directive. We can implement this simply by also allowing just the use of "name" in any place where "asmname" would be allowed (i.e., we can dispense with the "asm" part of the "asmname" directive). That way, we get the best of both worlds! >2. Any objections against allowing (working, that is) function attributes > in the implementation part? None that I can see - except if it makes things become more error-prone. 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

Some new features
by Frank Heckenbach 01 Jul '97

01 Jul '97

Here are a few features I'd like to see in gpc. I hope they can be implemented without much work... - Commandline options to specify the directory(ies) a) to search for units/modules (source or compiled) b) to put compiled modules (.o, .gpi, .gpm) c) to put compiled programs (executables). (They're similar to some BP options, except that BP uses the same for b) and c) which I think is a bad idea, so I'd prefer different options.) - Passing the actual size for untyped (resp. void) parameters, so it can be access with sizeof. (E.g., with untyped files (at least in BP) I often have to do things like "blockread(f,x,sizeof(x))", which could be simplified to "blockreadvar(f,x)" then.) And for better BP compatibility: - A function "Concat", equivalent to the operator "+" for strings. It can't be declared in system.pas since (in BP) it allows an arbitrary number of arguments. - Ignoring the BP directives "near" and "far" after procedure/function declarations (they're irrelevant to gpc, anyway) -- only in "--borland-pascal" mode, of course. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

bugs, incompatibity, function attributes
by Jan-Jaap van der Heijden 01 Jul '97

01 Jul '97

Hello, First: this is a small change to lang-specs.h to correctly pass directives from "specs" to gpc-cpp. GPC skips half of them. --- lang-specs.h.orig Mon Jun 2 02:01:51 1997 +++ lang-specs.h Tue Jul 1 00:00:18 1997 @@ -32,7 +32,7 @@ %{C:%{!E:%eGNU Pascal does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GPC__=%v1 -D__GNUC_MINOR__=%v2\ - %{!undef: %P}\ + %{!undef: %p %P} \ %c %{O*:%{!O0:-D__OPTIMIZE__}} %{traditional} %{ftraditional:-traditional}\ %{traditional-cpp:-traditional} %{trigraphs}\ %{g*} %{W*} %{w} %{pedantic*} %{H} %{d*} %C %{D*} %{U*} %{i*} %Z\ Then, I'm trying to get a somewhat borland-compatible syntax for external functions. GPC requires that the full declaration of a function is repeated, combined with the directive 'external': ----------------------------------------- unit Foo; interface function Bar(var i: integer): integer; implementation function Bar(var i: integer); integer; external; end. ----------------------------------------- Borland does it like this: ----------------------------------------- unit Foo; interface function Bar(var i: integer): integer; implementation function Bar; external; end. ----------------------------------------- ISO only mentions that "many processors provide, as an extension" 'external', but doesn't require it, let alone define the syntax to be used. Then, and this is a bug, GPC accepts this: ----------------------------------------- unit Foo; interface function Bar(var i: integer): integer; implementation function Bar(var i: integer); integer; external; attribute(stdcall); end. ----------------------------------------- The "attribute" part should be in the first declaration, not the second. The same error for other the "asmname" directive. Although it accepts the input, GPC doesn't do anything with the directives. (function attributes not surviving the GPI mechanism is a long-standing bug, but the "asmname" is silently ignored). To add to the confusion, this is how delphi declares a win32 API function imported from a DLL: ----------------------------------------- unit Foo; interface function Win32apiFunction(var i: integer): integer; stdcall; implementation function Win32apiFunction; external DLLfile name 'RealName'; end. ----------------------------------------- DLLfile is the name of the DLL (i.e. kernel32.dll), RealName need not be the same as Win32apiFunction: for 'MessageBox' the real name is 'MessageBoxA', to name one. A complete function declaration is not repeated, and while one attribute is in the declaration ('stdcall'), the other is in the implementation. GPC has no equivalent for the "DLLfile". But, if implemented, the automake mechanism could add an option "-lDLLfile" to the linker command line, something you have to do manually now. This is useful for all platforms, not just windows DLL's BTW. So: 1. Are there any reasons not to change the "external" declaration, at least for "borland" mode? 2. Any objections against allowing (working, that is) function attributes in the implementation part? Greetings, JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

Volatile!!
by Peter Gerwinski 30 Jun '97

30 Jun '97

According to Bernhard Tschirren: > Is it possible to decalare a variable volatile? Var Foo: __volatile__ Integer; > Other than that, the latest release is excellent. Many bugs were fixed! :-) Hope this helps, 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 [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Rhide that chuchoo train...
by Peter Gerwinski 30 Jun '97

30 Jun '97

According to Orlando Llanes: > > Is there a version of RHIDE that doens't lock up? The last time I > downloaded it, I used rhide12b.zip is there a newer version? rhide13b.zip. :-) To stay up-to-date with RHIDE, please read news://comp.os.msdos.djgpp, or look at http://www.tu-chemnitz.de/~rho/rhide.html from time to time. Hope this helps, 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 [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Long integers
by Peter Gerwinski 30 Jun '97

30 Jun '97

According to Frank Heckenbach: > > Thinking about it, it might be better to implement long integers as a > schema or object type (perhaps with PXSC operators?)... I have heared of a library "gmp" which could be a useful tool to achieve this. Just write a Pascal interface for it ... > BTW: Is there any information about schema types and/or PXSC available? > I don't know more about them than I saw in some examples. So do I. :-( > If I know more about them, it could be relatively easy to implement them... Think of a schema as a type declaration with parameters which can occur anywhere in the declared type: as array or subrange boundaries, or as a variant record selector. (I am not sure if the latter one really works.) For PXSC, it's even easier because operators are the only PXSC thing so far implemented in GPC. Procedure overloading will be the next one. And there is yet another syntax to define Modules (aka Units) which would probably be easy to implement if I really know how it looks like. > var x:array[1..10] of word; > > begin > x:=8932740732465987432659087423658294376597843265987432659786; > {fill this number into x (according to endianness, "0-padded" for > positive numbers, "F-padded" for negative ones)} I doubt whether this is really useful. Numbers of this size aren't usually typed in as decimal digits, but they are characterized as "2 pow 103 - 2 pow 97 + 3 pow 13". And you can always write a function which accepts a string or a chain of integers or whatever and returns a long number. > Would this be possible to do? The latter instruction seems more difficult. > "+" and "=" could be operators, implemented in Pascal. The requirement to > the compiler would be to convert such numbers into an array (and a length > value) automatically. Seems difficult, but since it's just like with > strings, I hope it's possible... Then the compiler would have to use this arbitrary-precision library (gmp?) by itself because a number must be multiplied by ten each time a digit is read. 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 [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Long integers (Was: Severe bug! :-(And some more bugs.))
by Frank Heckenbach 29 Jun '97

29 Jun '97

Peter Gerwinski wrote: > > Is "Integer(n)" supposed to support bigger types than LongestInt? > > No. Somebody else may implement that ... ;-) Thinking about it, it might be better to implement long integers as a schema or object type (perhaps with PXSC operators?)... BTW: Is there any information about schema types and/or PXSC available? I don't know more about them than I saw in some examples. If I know more about them, it could be relatively easy to implement them... > > The following program writes 0. ("+" doesn't seem to work correctly with > > big integers at all, telling from the asm code.) > > > > program x; > > var a:integer(128); > > begin > > a:=$FFFFFFFF; > > a:=a+1; > > writeln(integer(a)) > > end. > > This is correct: "a + 1" gets the integer value $100000000 in this > example; the cast to `Integer' yields an (uncatched)-: overflow and > the correct value 0 for the lowest 32 bits. The example was bad, but in fact a+1 did not get the correct value as the following programs shows (writes "0 0 0 0"). But obviously, it wasn't supposed to... program x; var a:integer(128); b:record c,d,e,f:cardinal end absolute a; begin a:=$FFFFFFFF; a:=a+1; writeln(b.f,' ',b.e,' ',b.d,' ',b.c) end. > > At least "=" seems to work with these types, which would make "Cardinal(128)" > > usable for ClassIDs (I hope)... :-) > > Sorry to have it taken out again! ;-) Then, we can use something like a record of 2 card64's (internally). Actually, thinking about it, it might even be better. If 64 bits are the "programmer ID" anyway, it could be easier to declare this once, and to declare only the other 64 bits (which is possible :-) for each class. And, when the "programmer ID" is declared (typically at the beginning of a unit), a base value for the "class ID" could perhaps also be given, so that the actually declared class IDs would be simple (small) numbers without the need of constants. I'm not sure about a good syntax for it, but I mean something like the following: const MyProgrammerID=$12345678; set base ID to MyProgrammerID,$0f000000 type x=object[1] ... which would result in an actual class ID of $123456780f000001. Unique and easy to type! :-) But it would also be useful (e.g. for constants for the big integers when they're implemented) to be able to specify (arbitrarily) long integers to be filled into a data structure (array of word or so...), analogous to arbitrarily long sequenced of characters filled into an array (aka strings :-). E.g.: var x:array[1..10] of word; begin x:=8932740732465987432659087423658294376597843265987432659786; {fill this number into x (according to endianness, "0-padded" for positive numbers, "F-padded" for negative ones)} if x+430985234985790342857=2938576498734697856 then ... end. Would this be possible to do? The latter instruction seems more difficult. "+" and "=" could be operators, implemented in Pascal. The requirement to the compiler would be to convert such numbers into an array (and a length value) automatically. Seems difficult, but since it's just like with strings, I hope it's possible... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Rhide that chuchoo train...
by Orlando Llanes 29 Jun '97

29 Jun '97

Is there a version of RHIDE that doens't lock up? The last time I downloaded it, I used rhide12b.zip is there a newer version? -- See ya! Orlando Llanes

1 0

Volatile??
by Bernhard Tschirren 29 Jun '97

29 Jun '97

Is it possible to decalare a variable volatile? I have been waiting for that a while now, and I expect it in 2.1!! :-) Other than that, the latest release is excellent. Many bugs were fixed! ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: Info files problem..
by Peter Gerwinski 29 Jun '97

29 Jun '97

According to Kevin A. Foss: > I downloaded the new EMX binaries of gpc (970624) and find that > I can't get the info files to display: "info -f gpc.inf" yields: info: > Cannot find the node "Top". Ah - sorry! I again installed a copy of `gpc.inf' which had suffered from an RHIDE bug and has a doubled line End Tag Table End Tag Table at the end. To repair it, load `gpc.inf' with your favourite ASCII editor and remove one of these lines. This holds both for EMX and for DJGPP. Hope this helps, 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 [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

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