Gpc

gpc@gnu.de

5400 discussions

Re: Pointer arithmetics, automatic `uses'
by Peter Gerwinski 24 Oct '97

24 Oct '97

According to The African Chief: > > This is getting very interesting :-) We now have many different > versions of FillChar! Which should I use? One that works, and among those the fastest one. > > BTW, pointer arithmetics ... should GPC allow constructions like > > > > (*$X+*) > > > > Var > > p, q: ^Char; > > > > p:= q + 42; > > > > or only > > > > p:= succ ( q, 42 ); ? > > > > Personally, I would prefer to allow only the second (Pointer being an > > ordinal type) and to consider the first (Pointer + Integer) an error, > > but it's technically easier to allow both, so I ask before I remove a > > bug somebody might consider a feature. ;-) > > Personally, I would keep both. I am not in favour of imposing > restrictions on programmers, unless it is for their own good! I > suppose we could assume that anyone who wants to use the first > permutation knows what he/she is doing. One "pro" for keeping both is that "Pointer - Pointer" yields an Integer, so "Pointer + Integer" should work too and act as a reverse of the first. > PS: - another point entirely; is there a switch that will enable > a particular unit (in this case SYSTEM.PAS) to be used > automatically, without putting it manually in the USES clause of > every source file? I am looking for something like > > "--auto-use=xxx.pas,yyy.pas,f:\gpc\zzz.pas", > > which I can then use from the command line, or put into to > GPCC.CFG file. This is planned, and `--auto-use=...' is a good suggestion for the name. Okay with everybody? (Or perhaps `--auto-uses=...'? Or just `--uses=...'?) 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]

2 1

Re: BPCOMPAT v1.10 -released!
by Frank Heckenbach 24 Oct '97

24 Oct '97

The African Chief wrote: > > For the other type declarations, I suggest you use the more modern GPC integer > > types (as invented some months ago), rather than the old style __modifiers__. > > (Also for real types.) > > Frankly, I am totally lost as far as that is concerned. Is there > any authoritative list of all the numerical types? I assume Peter's description in the announcement of GPC-970624 in <199706250026.CAA18851(a)agnes.dida.physik.uni-essen.de> can be considered authoritative: --- BEGIN QUOTE --- * 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) *) --- END QUOTE --- So I suppose, for "portable" BP compatibility, the "(n)" variants are best suited: type ShortInt = Integer (8); Byte = Cardinal (8); Word = Cardinal (16); LongInt = Integer (32); Comp = Integer (64); Integer = Integer (16); const MaxInt = $7FFF; {@@ better: High(Integer) as soon as High will be built-in} MaxLongInt = $7FFFFFFF; {@@ High(LongInt)} For the C integers, you can use the table above (e.g. "long = MedInt"). Single, Double and Extended are built-in already. Real can be left as it is (which is either Single or Double, dependent on a swicth, IIRC), or generally defined to Double, I don't know -- it's not 100% the same as in BP, anyway... Pointer is also built-in, BTW. > > Procedures assgined to procedural variables can be in the main program now, > > so you can remove this comment for ExitProc. > > I am still having some problems with this. Can you show us an example where this is a problem, so it can be fixed? Another detail concerning ExitProc: There is a little difference between how BP's and GPC's system.pas handle them. BP sets them to NIL before calling an ExitProc. The effect is, when an exit proc "forgets" to assign the next one to ExitProc, the chain will abort rather than infinitely calling the same exit proc. I think the following would be 100% compatible: to end do begin var Tmp: Pointer; while ExitProc<>nil do begin InOutRes := 0; Tmp := ExitProc; ExitProc := NIL; PProcedure (Tmp)^ end end; The following program demonstrates the effect: program x; {$ifdef __GPC__}uses system;{$else}{$f+}{$endif} var Next1, Next2: Pointer; procedure e1; begin ExitProc:=Next1; Writeln('ExitProc1') end; procedure e2; begin (* ExitProc:=Next2; *) Writeln('ExitProc2') end; begin Next1 := ExitProc; ExitProc := @e1; Next2 := ExitProc; ExitProc := @e2; end. > > Assign is built-in now, so you can remove it from system.pas. > > Done. Does it now cater for all file types? Currently only Text files and typed files (which are the same internally in GPC). Untyped files are very different (as declared in system.pas), a fact I'm not very happy with. I think, they will be changed to be like typed files, but probably not until GPC 2.1... > Basically, DOS is a beast of a unit to implement - especially the > Findxxx functions. There are still problems with a "DIR" listing > using these functions if there are .EXE files in the list. There > are all sorts of other problems as well. I don't think it will > ever be portable. I have given up on the DOS unit. If someone > else wants to do it, please feel free! I see the problems. I suppose, *if* we can make a C header to Pascal translator (which is a very difficult task), we can make use of some (hopefully portable) C system functions to emulate most of Dos (though this will probably require some amount of additional Pascal code)... I think this is a task to face after 2.1... > > Unit Printer: > > > > can be written now (at least for DJGPP). > > Done! BTW: Do you close the printer file it in a "to end do" statement? BP, AFAIK, doesn't do so, but it's better to do. > Ok - thanks. I note Frank's comments - and so I will leave "Val" > alone. > Frank - will your "Val" procedure deal with reals as well? Yes, there are different versions for the 10 basic integer types and the 3 real types (shortreal, real, longreal), which will all be "overloaded" to the name "Val". Integer subranges should also work then, bit fields (fields of packed records/arrays that are not complete bytes) might not work until some time later... > Yes, it is. This is how it is implemented in "AddNull", which was > in the strings unit before, but I have now moved it into the > system unit, since the system unit also uses that functionality. > > Any thoughts on whether the system unit should now export this > AddNull function so that it can be available globally? This would > introduce something which is not in the BP system unit. I'm not sure if it should, since something like this will be built-in later, so programs shouldn't rely on the version in system.pas. Besides, I think, the name "AddNull" could be unclear or ambiguous (though I doubt someone would write a procedure of this name operating on numbers... ;-). I'd rather call it something like "Str2CString" or so... > PS: - another point entirely; is there a switch that will enable > a particular unit (in this case SYSTEM.PAS) to be used > automatically, without putting it manually in the USES clause of > every source file? I am looking for something like > > "--auto-use=xxx.pas,yyy.pas,f:\gpc\zzz.pas", > > which I can then use from the command line, or put into to > GPCC.CFG file. I agree, I'd also like to have this -- especially for the system unit. It's planned to make this, perhaps even until 2.1. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

Re: Error while compiling simple Pascal-Program
by Peter Gerwinski 23 Oct '97

23 Oct '97

According to Christian Bockermann: > > I have installed version 2.3 of the gnu assembler (gas) but now I get an > error when compiling my pograms. I wrote a little test program like this : > > program test; > var ch : char; > begin > ch:='x'; > writeln(ch); > end. This program compiles well on my box. (Uh - I hate non-reproducable errors!)-: I am using version 2.8.1 of the GNU assembler. Maybe that's the problem? If you upgrade and the error is still there, it could be a good idea to run `gpc' with the options `-v --automake=-v'. 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

Integer types (was: BPCOMPAT v1.10 -released!)
by Peter Gerwinski 23 Oct '97

23 Oct '97

According to The African Chief: > > > For the other type declarations, I suggest you use the more modern GPC integer > > types (as invented some months ago), rather than the old style __modifiers__. > > (Also for real types.) > > Frankly, I am totally lost as far as that is concerned. Is there > any authoritative list of all the numerical types? It's in the GPC info documentation, section "Integer types", and there is also an Info node for each type. 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: Trapping I/O runtime errors in GPC
by Peter Gerwinski 23 Oct '97

23 Oct '97

According to Bill Currie: > On 23 Oct 97 at 10:43, Peter Gerwinski wrote: > > According to Jesper Lund: > > > Is there a (simple) way of trapping runtime I/O errors in GPC, like the {$I-} > > > compiler directive in Borland Pascal? [...] > > > > Not yet, but it is being worked on. (Interested to take part?;-) > > Agh, does that mean I have to pull my finger out? Of course not. I was referring to your work, and I simply wanted to attract co-workers to your project. (-; > I think I've got the compiler side working in an older beta, but the > rtl has to be modified to support it. > > Problem is, {$I-} could be even longer yet because I'm changing jobs > (cities too) soon and I don't know how long I'll be off the net > (going off shortly before 17 Nov) > > I should at least be able to get some patches relative to the latest > beta (I think I still have to download it) before then. This would mean that it would be in the next beta and in gpc-2.1 - which would be a good thing. Thanks in advance, 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: BPCOMPAT v1.10 -released!
by Peter Gerwinski 23 Oct '97

23 Oct '97

According to The African Chief: > > Any thoughts on whether the system unit should now export this > AddNull function so that it can be available globally? This would > introduce something which is not in the BP system unit. I would suggest to export it on request if an "extensions too" switch has been (*$define*)d. 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]

1 0

Re: Trapping I/O runtime errors in GPC
by Peter Gerwinski 23 Oct '97

23 Oct '97

According to Jesper Lund: > Is there a (simple) way of trapping runtime I/O errors in GPC, like the {$I-} > compiler directive in Borland Pascal? [...] Not yet, but it is being worked on. (Interested to take part?;-) > [...] to emulate the Borland 'Val' procedure. `Val' is being worked on as well. 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]

2 1

Error while compiling simple Pascal-Program
by chris＠bockermann.ping.de 23 Oct '97

23 Oct '97

Hello all there ! I have installed version 2.3 of the gnu assembler (gas) but now I get an error when compiling my pograms. I wrote a little test program like this : program test; var ch : char; begin ch:='x'; writeln(ch); end. and the error I get is : chris@bockermann:/home/chris/programs/pascal/test-prgs > gpc --automake test.p /tmp/cca00462.s: Assembler messages: /tmp/cca00462.s:4: Error: Unknown pseudo-op: `.local' /tmp/cca00462.s:5: Error: Rest of line ignored. First ignored character is `,'. /tmp/cca00462.s:6: Error: Unknown pseudo-op: `.local' /tmp/cca00462.s:7: Error: Rest of line ignored. First ignored character is `,'. /tmp/cca00462.s:8: Error: Unknown pseudo-op: `.local' /tmp/cca00462.s:9: Error: Rest of line ignored. First ignored character is `,'. /tmp/cca00462.s:10: Error: Unknown pseudo-op: `.local' /tmp/cca00462.s:11: Error: Rest of line ignored. First ignored character is `,'./tmp/cca00462.s:14: Error: Alignment too large: 15. assumed. /tmp/cca00462.s:37: Error: Alignment too large: 15. assumed. /tmp/cca00462.s:50: Error: Alignment too large: 15. assumed. /tmp/cca00462.s:58: Error: Unknown pseudo-op: `.section' /tmp/cca00462.s:61: Error: Alignment too large: 15. assumed. /tmp/cca00462.s:73: Error: Unknown pseudo-op: `.section' /tmp/cca00462.s:78: Error: Alignment too large: 15. assumed. Does anybody know, what's wrong ? -- Bis denn, Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

1 0

Pointer arithmetics (was: BPCOMPAT v1.10 -released!)
by Peter Gerwinski 23 Oct '97

23 Oct '97

According to Frank Heckenbach: > Until a (more optimized) version > of them will be built in, here are some replacements (a bit slower, but > should be portable and generate no warnings): [...] Pointer arithmetics is portable and can be used here to speed it up: Procedure FillChar ( Var Dest: Void; Count: Integer; C: Char ); Var DestArray: tCharArray absolute Dest; z: ^Char; begin (* FillChar *) for z:= @DestArray [ 0 ] to @DestArray [ Count - 1 ] do z^:= C; end (* FillChar *); (Similar for `move'.) BTW, pointer arithmetics ... should GPC allow constructions like (*$X+*) Var p, q: ^Char; p:= q + 42; or only p:= succ ( q, 42 ); ? Personally, I would prefer to allow only the second (Pointer being an ordinal type) and to consider the first (Pointer + Integer) an error, but it's technically easier to allow both, so I ask before I remove a bug somebody might consider a feature. ;-) 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]

2 1

BPCOMPAT v1.10 -released!
by The African Chief 23 Oct '97

23 Oct '97

Hi all I have just uploaded BPCOMPAT v1.10 to agnes (in the contrib directory). You can download it as; ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/bpcompat.zip and ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/bpcompat.txt This version contains some bug fixes, and some stuff to improve portability (especially of the SYSTEM unit). Users of Linux and unix systems should find that the SYSTEM unit will now compile ("__UNIX__" is now predefined for Linux, Solaris, and FreeBSD - other unix users will need to define it manually). There are probably still some remaining bugs, and the package is still not a complete replacement for the BP RTL. However, things are improving. The ZIP file has been restructured (with a directory tree) so that the files are easier to locate and manage. The package needs improvement, and all contributions are welcome! BUGS ---- If you find bugs, please try to fix them - but please report them to me as well. If you fix them, please let me have a copy of the fix. Happy coding! Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Author of: Chief's Installer Pro 4.01 for Win16 and Win32: Winner of PC PLUS Magazine Gold Award (April 1995 U.K. edition) http://ourworld.compuserve.com/homepages/African_Chief/ ftp://ftp.demon.co.uk/pub/ibmpc/win3/apps/chief/pro/chief401.zip

2 2

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