Gpc June 1997

gpc@gnu.de

25 participants
172 discussions

Files
by berend＠beard.nest.nl 01 Feb '02

01 Feb '02

* Moved (from: gpc) by Berend de Boer using timEd 1.10.b3+. Peter Gerwinski wrote in a message to Berend de Boer: PG> I tried to use Extended Pascal "binding" to assign a file PG> variable to an external -- existing -- file. I just copied PG> the "Assign" pro- cedure by Berend as published in PG> borland2ep.doc. It does not always work: I often get a PG> runtime error saying that the file did not exist. If you can repeat it, compile with another Extended Pascal compiler, for example Prospero's one. If that fails too, there is really something wrong with the code. But I suspect gpc. You're using which OS? Groetjes, Berend (-: fido: 2:281/527.23 email: berend(a)beard.nest.nl

4 3

GNU Pascal beta version gpc-970624
by Peter Gerwinski 05 Jul '97

05 Jul '97

Hello everybody! Here again is a new version of GNU Pascal: gpc-970624. Since we are aiming gpc-2.1 now, this is considered a *beta* version. :-) GPC integrated into GCC ======================= We succeeded to integrate the GPC source tree into that of GCC. Now GPC is compiled and installed just like other GNU compilers. Advantages of this distribution to the users of GPC are: * Easier configuration: GPC is configured automatically when you configure GCC. To build it, simply type "make LANGUAGES=pascal" in the GCC directory. No more VPATH problems with some (read: Solaris) versions of `make'. * Building GCC, G++, ObjC, GPC and G77 (GNU Fortran) from a single source tree is now possible. Benefits for GPC developers: * Easier adaption to different GCC versions. * Better functional separation of GPC sources from the GNU back-end (code shared with GCC) and the GPC specific code. * A first step of further integration of GPC into the main GCC distribution? Other changes since gpc-970510 ============================== General news: * The version number is now again produced manually, so it does reflect the date of release, not of compilation. * The GCC_MINOR version number now yields the expected result of `7'. Bug fixes: * Concatenation of more than two String constants now results in a constant again, as it should be. * Chars passed to formal String parameters work now. * The warning "return type of `main' is not `int'" which occured with Pentium optimization is gone. * Enumerated types now can be exported by Units or Modules and are type-checked more strictly. * Pointers to single-character identifiers like `^A' now work as type specifications in variable declarations. (They no more crash with `^A' character constants.) * GPC no more crashes on errorneous constant definitions. * GPC no more crashes on errorneous initializers of structured variables. * AutoMake with (*$L foo.c *) sometimes appeared to chose the compiler to run at random, and it threw the dice to decide whether to recompile the file or not. This feature is replaced now by a more traditional method: (i) Derive the compiler to run from the extension of the file, and (ii) decide whether to recompile or not from the date of the last change. * Fixed some obvious bugs in the lexical analyzer which never showed up. (The situation was too exotic to appear in praxis.) * Extended Pascal's `ReadStr' (for BP users: this is EP's equivalent to `Val') now accepts numeric values in non-zero-terminated strings. (GPC's strings are not zero-terminated.) * Initialized strings no longer get a trailing `chr ( 0 )'. (Initialized `CString's (aka `pChar's) do; see below.) * Initialization of structured variables containing other structured variables works now. * OOP: Nested subfunctions of methods work now. * Pointer arithmetics now also works on the DEC Alpha, where `SizeOf ( Pointer)' is different from `SizeOf ( Integer )'. * Objects now also work on the DEC Alpha, where the type for sizes of objects is not `Integer' (32 bits) but `LongInt' (64 bits). * Packed arrays now also work on the DEC Alpha which does not like to access misaligned 64-bit words. * Schemata now also work on the DEC Alpha. * Functions returning `Char' values now also work on the DEC Alpha. * Module (Unit) constructors and destructors now also work on the DEC Alpha. (You see: The DEC Alpha is a good platform to test GPC!) UCSD (and Borland) Pascal: * `Exit' handles function return values correctly now. * Functions returning `String' now default to return `String ( 255 )'. Without the `--borland-pascal' switch, a warning is given. (According to EP, `String' is a Schema type in GPC and not limited to 255 characters.) Borland Pascal: * Control character constants like `^A' are now restricted to `^A..^Z' because `^^' happened to crash with double pointer dereferences, etc. (BP has a bug here and does even accept `^;' and `^ ' (with a blank). They might consider it a feature ...) * `Abstract' can be redeclared now. (BP has no built-in `Abstract', but Turbo Vision defines one.) * Assigning contant values to `pChar' (aka `CString') variables works now. * The `write' and `writeln' procedures now work for `pChar's, too. * Calls to procedural parameters now work in expressions, too. * Type casts now work like in BP, no more like in C. Delphi: * GPC now implements the function return `Result' variable. (According to EP it was always possible to implement it manually by declaring "Function foo ( bar: Integer ) = Result: Integer". (And it still is.:)) Extended Pascal: * Subarray access `a [ i..j ]' for non-Strings is now warned about in `--extended-pascal' mode. * Pointers to pointers to undiscriminated Schemata (e.g. Strings without specified length) work now. * Schemata are (read: should be;) initialized properly now in all situations. GNU extensions: * A new option `--executable-file-name' or (*$executable-file-name="foo"*) now provides an alternative mechanism (apart from `-o foo') to specify the executable output file. While `-o' can only be specified at the command line, this switch can be written in the source as a compiler directive. If the name is not explicitly given, it is derived from the source file name which contains the `Program' declaration. * A new option `--ignore-function-results' or (*$ignore-function-results *) now allows to ignore values returned by functions without (*$X+*). Since this is not as dangerous as, say, pointer arithmetics, it has got a separate switch. It has a counterpart `--no-ignore-function-results'. * `--extended-syntax' now has a counterpart `--no-extended-syntax'. * `TypeOf ( MyObj )' is not accepted as an lvalue any more; instead, you can use `AssignType ( MyObj, MyVmtLink )'. * Assignment of the return value of a function through `asm' statements is now recognized, so you won't get a superfluous "warning: return value not assigned" any more. * Pointer arithmetics: `inc ( p, n )' now increases the address pointed to by `n * SizeOf ( p^ )' rather than just `n'. * GPC has new integer types now. Below is a table with their sizes in bits and their equivalents in (GNU) C. The size is the same for all platforms I have access to, but I am not sure whether this will always and everywhere be the case. However, compatibility to GNU C is guaranteed to work to the extend of the GNU GPL. ;-) The `*Int' types are signed (integer), the `*Card' types unsigned (cardinal numbers). The `*Word' types are unsigned, too, but should be thought of having undefined sign; they are intended to be used where signedness does not matter. Bits Signed Unsigned undefined (GNU) C equivalent 8 ByteInt ByteCard Byte [signed|unsigned] char 16 ShortInt ShortCard ShortWord short [unsigned] int 32 Integer Cardinal Word [unsigned] int 32 MedInt MedCard MedWord long [unsigned] int 64 LongInt LongCard LongWord long long [unsigned] int 64 LongestInt LongestCard LongestWord long long [unsigned] int In addition, you can define the number of bits for `Integer', `Cardinal', and `Word' types by putting it in parentheses, Type Int16 = Integer ( 16 ); (* 16 bits *) Unsigned17 = Cardinal ( 17 ); (* 17 bits; stored in 32 bits *) (* except when in packed arrays *) (* and records (or on machines *) (* with 17-bit registers:-). *) Answer = Word ( 42 ); (* Stored in 64 bits *) The size is rounded up to the next unit the machine can access, usually a power of 2 with 8 bits being the smallest possible size. * Subrange types can be packed now: Type Foo: -12..127; (* Takes 4 bytes (fast access) *) Bar: packed -12..127; (* Takes 1 byte (saves memory) *) Where to get it =============== The source is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/ together with binaries for DOS (DJGPP), DOS and OS/2 (EMX), Linux (ELF), and FreeBSD. Acknowledgement =============== We thank everybody who took part in the discussion about integer types and other extensions for good ideas. We thank Larry Carter, Frank Heckenbach, Abimbola A. Olowofoyeku, Markus Gerwinski, Berend de Schouwer, Maurice Lombardi, Phil Robertson, Bernhard Tschirren, and Dario Anzani for finding the bugs. We thank the IFF (Institut fuer Festkoerperforschung) of the FZ Juelich, Germany, for the opportunity to test this new version of GPC on a DEC Alpha computer. Greetings, Peter Gerwinski Jan-Jaap van der Heijden <peter.gerwinski(a)uni-essen.de> <j.j.vanderheijden(a)student.utwente.nl>

2 1

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

Re: GNU Pascal
by Peter Gerwinski 29 Jun '97

29 Jun '97

According to mtdew: > > Hi, Im very excited about using your GPC for programming some IRC > interfaceses (server and client) However, Im new to using GPC (not new to > borland pascal) and have been finding it difficult to find information on > commands/functions/procs that are specific to GPC. Indeed, our documentation is somehow outdated and incomplete. A lot of requests for extensions of GPC arise from the fact that nobody knows how to use the existing features. Sorry for that. If you want to help us to improve the GPC documentation, be welcome! (-: > I'm very interested in any information about opening sockets, so > that I can use them to connect with other irc servers.. (Or maybe even > just other servers of any sort of port) Is there support for this? > (Something similar to C's, 'socket'?) I don't know much about sockets (would like to know, however), but the GPC FAQ describes how to use arbitrary C libraries from GNU Pascal: 8< ---- begin (* FAQ extract *) ------------------------------------------ How do I use <insert_your_function_here> from the C library? ============================================================ GNU Pascal can use every function of your C library, but it may be up to you to write declaration of an external function, before you can use it. Consider the function `sleep'. `man(3) sleep' reveals: --------------------------------------------------------- NAME sleep - Sleep for the specified number of seconds SYNOPSIS #include <unistd.h> unsigned int sleep(unsigned int seconds); --------------------------------------------------------- This small demo program shows how to use `sleep' in a Pascal program: --------------------------------------------------------- program SleepDemo; type word = __unsigned__ integer; function sleep(seconds: word): word; C; var result : word; begin result := sleep(10); end. ---------------------------------------------------------- 8< ---- end (* FAQ extract *) -------------------------------------------- If you write a GPC Unit (or Module) to access sockets and such, be welcome to give us a copy we can publish with GPC. 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:

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