Gpc November 1997

gpc@gnu.de

32 participants
113 discussions

Weird ASM error...
by Orlando Llanes 09 Nov '97

09 Nov '97

I'm using the latest GPC Beta (971101?), and when I type in the following fragment of code: PROGRAM Foo; BEGIN asm('movl %eax, 0xa0000' ); END. it compiles fine, but when I run it, the program reports a GPF. I don't understand why it does that, I've even tried push'ing and pop'ing eax, but it still does the same thing. See ya! Orlando Llanes "Hey, we all did the drug thing, we all did the money thing, and eventually you find out that none of that stuff fixes anything, and we have nowhere else to go except to evolve spiritually and intellectually" -- Meredith Brooks "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve/homepages/Monkey414

1 0

Re: 2 suggestions about Units
by Peter Gerwinski 09 Nov '97

09 Nov '97

According to Hans Ecke: > > 1.) heredity and virtuall routines for units (yes, I mean objects!) > [...] > So what I would like to see would be: > > ///////////////////////////////////////////////// > > unit graph_fast(graph); If I understand this correctly, you mean that your unit `graph_fast' shall export everything that `graph' does but override `putpixel' and `line' with new implementations. Well, this is just overloading of procedures, nothing "virtual". (* Something like "virtual procedures" in units would be the following: Program X uses unit A and calls a procedure `foo' in A. Unit B uses unit A too and overrides `foo'. "Virtual" means that program X - which does not use B directly - in fact calls `B.foo', not `A.foo'. You do not really mean this, do you? { Well ... I just discovered: you *do* mean this. (See below.) } *) The mechanism you suggest requires qualified identifiers, so procedures with the same name can coexist in different units in the same project. This is planned for gpc-2.2. Up to then, you can get the intended effect of `Unit graph_fast ( Graph )' using the following kludge: Unit Graph_Fast; uses Graph; Procedure Fast_PutPixel ( ... ); (* Implemented below *); Procedure Fast_Line ( ... ); (* Implemented below *); Procedure Bar ( ... ); External; (* "Inherits" from `Graph' *) ... Implementation (* Implement `Fast_PutPixel' and `Fast_Line' *) end. Once qualified identifiers will exist, you can get rid of the `Fast_' name prefix. Having said that, it might be a good idea to implement your idea "Unit foo ( bar )" as a shortcut to produce the result sketched above. *Perhaps* in gpc-2.2. > procedure putpixel(x,y:integer); > begin > writeln(logfile,`Putpixel with parameters `,x,`,`,y); > inherited putpixel(x,y); > end; Okay, now you want `Graph' (or `Fast_Graph') use your overridden `PutPixel' instead of its own `PutPixel'. This can only be done with pointers, like Frank pointed out. This *is* virtuality. If you want to implement that, modify `Graph' such that `PutPixel' is a procedural variable: Var PutPixel: Procedure ( ... ); Then you must, of course, initialize it (perhaps in `InitGraph'), i.e. manually write a "constructor" for your "object". I have done this in the past (BO4), and it works in a great way. (* Since our `Graph' unit is *not* a port from Borland Pascal but was rewritten from scratch and comes with full source (C and Pascal), it is *no problem* to modify it this way. :*) To override the "virtual procedure" `PutPixel', your `Fast_Graph' unit needs to do nothing but to assign a new value to that `Putpixel' variable. You can do it with the current version of GPC (or with BP for that matter). > Maybe one could consider also Multi-heredity (is this a understandable > word?) It is, but the correct word is "multi-inheritance". With units, this would be no real problem - provided that we are not talking about virtual procedures. When it comes to virtual procedures, the same problems arise for units as for objects. Summary: The feature you are asking for does not (yet?) exist, but you can work around them relatively easily. But: If you want to have the features of objects for your library, why don't your libraries export objects instead of "ordinary" procedures? I am currently writing a library (BO5) which does it that way: All input/output is done through objects having virtual methods, so you can easily replace `PutPixel' with a different routine - and the whole library will work with this new procedure. Borland's "Graph" (BGI) API is not the ultimate way to implement a graphics library. I suggest to write the library using objects and to provide some ordinary procedures that use the objects as an interface for compatibility. > 2.) Making Libraries from units > I don't know if this task allready done. It is - for the objects. You can put them together in an `.a' file. (See the documentation of `ar' and `ranlib'.) For the interfaces (`.gpi' files) this is not possible at the moment. Your "parent unit" mechanism would provide an easy way to "concat" `.gpi' files, so the calling program only needs to use *one* unit and gets the functionality of all of them. Not a bad idea. Such a Unit BO5 ( Tools, Objects, Events, Displays, whatever ); (* "BO5" is the name of my planned ultimative library; you can substitute "EFLIB" if you prefer something already existing. ;*) Interface Implementation end. would produce one large `.gpi' file such that "uses BO5" would give all the functionality of `Tools', `Objects', etc. to the program and tell the linker to link all the files `tools.o', `objects.o', etc. (* Perhaps Borland's syntax "Library BO5" instead of "Unit BO5" would be a reasonable extension to directly produce `libbo5.a', i.e. automatically invoke `ar' and `ranlib'? *) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

3 3

Re: Binary installation
by Clyde Meli 09 Nov '97

09 Nov '97

> Peter, > > Thank you for your help, first with the binary installation on RedHat 4.2 > (which failed), then with compiling gpc (which worked after an aborted > start :-) > > I now have the 971001 beta (2.7.2.3) running and compiling some simple > programs. But I still have a ways to go. This code, which compiled > previously, fails now with a message that there is an undeclared > identifier `Ch' in function Isalphanum on line 17. > I still haven't succeeded in compiling the 971001 beta (2.7.2.3) under solaris 2.5.1 as previously posted. No suggestions have been made so far. I got the same beta binary precompiled for dos and it seemed very stable to me at least. I wish I could get it to work for this week. Regards, Clyde cmeli(a)cis.um.edu.mt

1 0

Re: Binary installation
by Peter Gerwinski 09 Nov '97

09 Nov '97

According to Tom Dye: > > After using gpc for several months I upgraded to the latest > beta binary and managed to break everything. [...] My machine is running > Linux RedHat 4.2. > > [...] > > /tmp/cca02238.i:1: numeric constant with no digits This problem once occured with an old version of `libc.so'. You are possibly using `libc.so.5.3.12'. Upgrading to `libc.so.5.3.20' or above might solve your problem. Alternatively, you can compile your own GPC. That's not that hard on a Linux box: Get the GCC source `gcc-2.7.2.[1-3].tar.gz', `tar xzf' it, rename the subdirectory `gcc-2.7.2.[1-3]' to `gpc-971001', then do `tar xzf gpc-971001.tar.gz; cd gpc-971001; ./configure; make CFLAGS=-O3 LANGUAGES=pascal; make CFLAGS=-O3 LANGUAGES=pascal install'. Hope this helps (please report if it does), Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

3 4

probs compiling current beta GPC
by Clyde Meli 08 Nov '97

08 Nov '97

I don't think my previous post got through - If they did please excuse this repetition. I'm having problems compiling the beta under Solaris 2.5.1/gcc 2.7.2.3 - I had problems with gcc 2.7.2.1 also so I installed gcc 2.7.2.3. /usr/local/bin/gcc -c -DIN_GCC -DGPC -DSVR4 -O3 -I. -I.. -I. -I./.. -I./.. /config gpc-lex.c In file included from gpc-lex.c:102: hash.h:122: `AND_' undeclared here (not in a function) hash.h:122: initializer element for `wordlist[24].token' is not constant hash.h:125: `NOT_' undeclared here (not in a function) hash.h:125: initializer element for `wordlist[27].token' is not constant hash.h:126: `NIL_' undeclared here (not in a function) hash.h:126: initializer element for `wordlist[28].token' is not constant hash.h:136: `MOD_' undeclared here (not in a function) hash.h:136: initializer element for `wordlist[38].token' is not constant hash.h:153: `DIV_' undeclared here (not in a function) hash.h:153: initializer element for `wordlist[55].token' is not constant hash.h:161: `SET_' undeclared here (not in a function) hash.h:161: initializer element for `wordlist[63].token' is not constant hash.h:176: `CONST_' undeclared here (not in a function) hash.h:176: initializer element for `wordlist[78].token' is not constant make[1]: *** [gpc-lex.o] Error 1 make[1]: Leaving directory `/usr1/local/src/GNU/SOURCE/gpc-971001/p' make: *** [gpc1] Error 2 Is there a solution to compiling the beta? Regards, Clyde

1 0

Re: Paramstr(0) in ASM...
by Peter Gerwinski 07 Nov '97

07 Nov '97

According to The Kilobug Team: > > Do you know how to access the program directory (like Paramstr(0) > does) from an ASM program? If the main program has been compiled with GPC, it puts a pointer to the vector of parameters on a global variable `Gpc_argv', and `Gpc_argc' carries their number. In Pascal syntax, you can access them directly using Const many = 1024; (* or whatever *) Type ArgVector = array [ 0..many ] of CString; Var GpcArgC: asmname 'Gpc_argc' Integer; GpcArgV: asmname 'Gpc_argv' ^ArgVector; You know how to access such variables from ASM. 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/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Separate Compilation
by Peter Gerwinski 07 Nov '97

07 Nov '97

According to richard.kerry(a)quantel.com: > > Hello, > Could somebody please either : > 1. Direct me to - info -f gpc -n "Source structures" at least explains how to use Units, and in info -f gpc -n "Extensions" you can read about Modules. This second documentation is somehow outdated; many things which are mentioned as missing features are implemented meanwhile. > or : > 2. Send me - > a comprehensive explanation of separate compilation using gpc, including > examples that clearly show which bits are in different files and how the > other bits pick up their definitions. And also including any > alternate/non-standard/old-fashioned techniques that are still usable. Coming below. > I am working on a very large project, developed using Oregon Pascal. The > separate compilation is done by each module (eg fred.pas) having a header > file (eg fred.def) containing all the procedures, functions, types and > constants it wishes the rest of the world to know about. All the routines > in the header are 'external'. The modules all contain their own global > variables; if any need to share, this is done by access procedures, or > records shared via pointers. There is no > module/unit/import/export/interface/implementation system involved. The > modules are compiled individually, using #include (%include in Oregon) to You can also use (*$i Foo *) or (*$include "foo.pas" *) or (*$include <foo.pas> *). > pick up any external definitions and references required, and then linked. > I want to mechanically translate all these modules to gpc, so I'd prefer a > mechanism, if there is more than one available, that uses a structure as > similar as possible to the one we are currently using. The closest approximation to Oregon Pascal (as you describe it) which is currently possible with GNU Pascal is to use the "somewhat simpler GPC modules" described in `info -f gpc -n Extensions'. When `foo.pas' reads; Module Foo; Var x: Integer; Procedure y; begin (* y *) writeln ( 'y' ); end (* y *); end. Then your `foo.def' can be (* foo.def *) Var x: __external__ Integer; Procedure y; External; and $including `foo.def' into the main program and linking with `foo.o' will have the desired effect ... uh - sh** (sorry!) it does not work! :-( :-( While implementing other things I threw away this one. The reason is that this feature turned into a bug when using Extended Pascal Modules or UCSD/Borland Pascal Units. Okay, this "GPC specific module" is very close to yet another type of Module defined in the PXSC standard. The only difference is that PXSC wants the reserved word `global' in front of each declaration that is to be exported. That's certainly more reasonable than to export just everything (like GPC did until February 1997 or so). It is planned to implement these PXSC modules into GPC. So you can either wait until GPC will have PXSC modules and then use Module Foo; Global Var x: Integer; Global Procedure y; begin (* y *) writeln ( 'y' ); end (* y *); end. --- (* foo.def *) Var x: __external__ Integer; Procedure y; External; --- Program Bar; (*$I foo.def *) ... or use UCSD/Borland-style Units Unit Foo; Interface Var x: Integer; Procedure y; Implementation Procedure y; begin (* y *) writeln ( 'y' ); end (* y *); end. --- Program Bar; uses Foo; ... or Extended Pascal Modules Module Foo Interface; Export FooStuff = ( x, y ); Var x: Integer; Procedure y; end. --- Module Foo Implementation; Procedure y; begin (* y *) writeln ( 'y' ); end (* y *); end. --- Program Bar ( Input, Output, Whatever ); Import FooStuff; ... 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/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Hex output.
by Dr E. Buxbaum 07 Nov '97

07 Nov '97

> From: Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> > Subject: Re: Hex output. > To: richard.kerry(a)quantel.com, gpc(a)hut.fi > Date: Wed, 5 Nov 1997 14:46:11 +0100 (MET) > According to richard.kerry(a)quantel.com: > > > > Does gpc have a built-in mechanism for converting a number to hexadecimal, > > for use in write(ln) or just as a number to string conversion ? > > No(t yet;-). > > > Oregon Pascal uses a negative field width to denote hex output (which I > > believe is sometimes also used to denote left justification), and Vax > > Pascal has a built-in 'hex( num, width )'. > > I do not think it's good to use negative field widths for this purpose > (except, perhaps, for compatibility reasons). The Vax syntax, OTOH, > seems quite nice for me. > > Right now we are still trying to finish up gpc-2.1, but we might take > this into account for gpc-2.2. > > Hmm ... what about something like `NumBase ( base, num, width )' to > allow for arbitrary bases like in `2#101010'? May be that sort of thing should be left to libraries, rather than build into the run time system. The main advantage of the Wirth family of languages, compared to comitte languages like, say, Ada, has always been that their syntax was limited to the necessary. It is easy enough to write a little library to read and write hex numbers and to convert them to and from integers and strings. Copying any odd feature from any odd Pascal compiler out there will create something big and cumbersome, that nobody in the end will be able to handle anymore.

1 0

Paramstr(0) in ASM...
by The Kilobug Team 07 Nov '97

07 Nov '97

Hi! Do you know how to access the program directory (like Paramstr(0) does) from an ASM program? Thanx -- -= The Kilobug Team =- DOS Real&Protected mode programming. Home page: http://www.planetepc.fr/users/kilobug/ NEW site (beta, french obly): http://www.mygale.org/~kilobug/

1 0

Separate Compilation
by richard.kerry＠quantel.com 06 Nov '97

06 Nov '97

Hello, Could somebody please either : 1. Direct me to - or : 2. Send me - a comprehensive explanation of separate compilation using gpc, including examples that clearly show which bits are in different files and how the other bits pick up their definitions. And also including any alternate/non-standard/old-fashioned techniques that are still usable. I am working on a very large project, developed using Oregon Pascal. The separate compilation is done by each module (eg fred.pas) having a header file (eg fred.def) containing all the procedures, functions, types and constants it wishes the rest of the world to know about. All the routines in the header are 'external'. The modules all contain their own global variables; if any need to share, this is done by access procedures, or records shared via pointers. There is no module/unit/import/export/interface/implementation system involved. The modules are compiled individually, using #include (%include in Oregon) to pick up any external definitions and references required, and then linked. I want to mechanically translate all these modules to gpc, so I'd prefer a mechanism, if there is more than one available, that uses a structure as similar as possible to the one we are currently using. Thank you all in advance. Richard. PS. I apologize to anyone who has already seen this message. We've had an email problem and I suspect my previous attempt to send this went into hyperspace...

1 0

← Newer
1
...
6
7
8
9
10
11
12
Older →

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