Gpc November 1997

gpc@gnu.de

32 participants
113 discussions

undeclared identifiers
by Tom Dye 16 Nov '97

16 Nov '97

Hello all, A while back I forwarded a bit of extended Pascal code that I thought should compile with gpc, but doesn't. This is example 1) below. gpc complains that the identifier `I' is not declared and goes on to complain about the comparison of I with 2 not being a boolean type. I've been tinkering to see if I can figure out what is going on and found that I can get the code to compile if I use the module-declaration = module-heading[ `;' module-block] form rather than the module-declaration = module-heading module-identification `;' module-block form. The modified code from example 1) is given as example 2). This compiles without warnings. I couldn't find anything in the standard about when to use one form of module and when to use the other, so I typed in some of the code examples provided with the standard to see how gpc performs with (hopefully) correct extended Pascal code. I discovered that gpc compiles almost everything that I tried. It does not compile the example module `generic-sort' that is given on pages 129-130 of the standard. For convenience, I include this code as example 3). This code fails to complile with message that `greater' and `swap' are undeclared identifiers, which reminds me of the messages reported for example 1). This module also uses the module-declaration = module-heading module-identification `;' module-block form. I suspect that I have found something that gpc does not do correctly, but I am far from confident that my suspicion is correct. Here are my other suspicions: a) I don't have gpc built correctly. I had some problems getting gpc to compile on my Linux box and can't really say what I did to make it compile--that is which change really made a difference. Could I be having problems with an incorrectly built gpc? b) the code in examples 1) and 3) relies on a feature of extended Pascal that gpc does not yet implement. I am relatively new to gpc and to extended Pascal and can't answer this one myself. Does the code in examples 1) and 3) fail because of an unimplemented feature of extended Pascal? Thanks for your help! Tom Thomas S. Dye, Ph.D. Home: 813 16th Avenue, Honolulu, Hawaii 96816. Voice (808) 734-2087. Work: International Archaeological Research Institute, Inc., 949 McCully St., Suite 5, Honolulu, Hawaii 96826. Voice (808) 946-2548; Fax 943-0716. Example 1) module charbug interface; export charbug = (IsAlphaNum); function IsAlphaNum (ch : char; i : integer) : boolean; end. module charbug implementation; function IsAlphaNum; begin if i > 2 then IsAlphaNum:= ch in ['A'..'Z','a'..'z','0'..'9']; end; end. Example 2) module charbug; export charbug = (IsAlphaNum); function IsAlphaNum (ch : char; i : integer) : boolean; end; function IsAlphaNum; begin if i > 2 then IsAlphaNum:= ch in ['A'..'Z','a'..'z','0'..'9']; end; end. Example 3) module generic_sort interface; export generic_sort = (do_the_sort, max_sort_index, protected current_pass => number_of_passes, protected swap_occurred_during_sort); type max_sort_index = 1..maxint; procedure do_the_sort(element_count : max_sort_index; function greater(e1, e2 : max_sort_index) : boolean; procedure swap(e1,e2 : max_sort_index) ); var current_pass : 0..maxint value 0; swap_occurred_during_sort : boolean value false; end. module generic_sort implementation; procedure do_the_sort; var swap_occurred_this_pass : boolean; n : max_sort_index; begin current_pass := 0; swap_occurred_during_sort := false; repeat swap_occurred_this_pass := false; current_pass := current_pass + 1; for n := 1 to element_count - 1 do if greater(n, n + 1) then begin swap(n, n + 1); swap_occurred_this_pass := true; end; swap_occurred_during_sort := swap_occurred_during_sort or swap_occurred_this_pass; until not swap_occurred_this_pass; end; { do_the_sort } end.

1 0

Re: size of strings (was without subject)
by Peter Gerwinski 16 Nov '97

16 Nov '97

According to Kevin A. Foss: > > [...] Just wondering, but do you realize that if you define > rec as a packed record, you apparantly lose this additional byte. This > doesn't really hurt much as the chr(0) isn't used yet, but I don't know > if it will cause problems down the road. Sorry - I forgot: The change was on 31 October, so in fact *you* get a size of 16 due to 32-bit alignment, and *I* get a size of 16 due to that additional byte. (-; With `String ( 4 )' instead of `String ( 3 )', the current beta version will still reserve 16 bytes while my development version will reserve 20 (due to the 32-bit alignment). :-) (Yes, I want to release the next (final?) beta soon, but I don't dare to promise a date due to some bad experience ... ;-) 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: Variant records (was without subject)
by Peter Gerwinski 16 Nov '97

16 Nov '97

According to Christian Bockermann: > > I have a little question concerning variant records and packed arrays. [...] According to myself (Peter Gerwinski): > > !! You have discovered a bug in GPC: The compiler had forgotten to store > the capacity of the string in the variant record. I will fix it as > soon as possible - thanks for the report. > > To work around, manually assign `x.rec.name.capacity:= 3' before you > assign a value to `x.rec.name'. Here is the fix: In `util.c', function `contains_file_or_schema_p()', change case RECORD_TYPE: to case RECORD_TYPE: case UNION_TYPE: Then it works. Greetings, Peter PS to Christian: Gib Deinen E-Mails besser ein "Betreff". ;-) 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: your mail
by Kevin A. Foss 16 Nov '97

16 Nov '97

On Sun, 16 Nov 1997 18:00:03 +0100 (MET), Peter Gerwinski wrote: > * Recent beta versions of GPC reserve one additional byte in each string > for appending a `chr ( 0 )' character for sake of compatibility to C > - which is not yet used. In future versions, byte 11 will be zero, and > only byte 12 will have random bits when the length of the string is `2'. > (That's why the size of the string is 12, not 11.) I've been playing around with this example... for some reason it interests me. :) Just wondering, but do you realize that if you define rec as a packed record, you apparantly lose this additional byte. This doesn't really hurt much as the chr(0) isn't used yet, but I don't know if it will cause problems down the road. E.g. if you put 'ABC' into the string instead of 'AB' you see the bits for the letters but there is no 12th random bits byte, and sizeof(x.rec) yields 15. Should it preserve the byte even when the string is part of a packed record? -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

Re: your mail
by Peter Gerwinski 16 Nov '97

16 Nov '97

Hallo, Christian! Hello, everybody! According to Christian Bockermann: > > I have a little question concerning variant records and packed arrays. In schoolwe wrote a little program with a declaration part like this : > > var > x : RECORD > CASE Boolean OF > False :( > rec:Record > name : String[3]; > number : integer; > end); > true :( > field:packed array [0..47] of boolean > ); > end; > > [...] > > So I expected the output to be > 1.) the binary decoding of the length of the string, like > 00000010 > 2,3.) binary decoding of the ascii-code of the characters in the string, like > 01000001 01000010 > 4.) some 8 random bits > 01010101 or something similar... > 5.) the 16-bit decoding of the integer variable, like > 00000000 00001001 The output depends on the internal representation of strings and integers in your particular Pascal compiler. The result you expected is okay for Borland Pascal and obviously for Think Pascal as well, but GNU Pascal uses a different scheme to represent strings and integers. If you examine `SizeOf ( x.rec.name )' and `SizeOf ( x.rec.number )' you will see that they are 12 and 4, not 4 and 2. The "12" is because GPC's strings comply to the ISO-10206 standard for Extended Pascal which (a) requires that the "capacity" (maximum length) of the string is stored in the variable and (b) does not limit the length of the string to 255 characters. This way, we have an overhead of two integers instead of one byte in the string. The "4" is because GPC is a 32-bit compiler, so `Integer' has four bytes instead of two. (And `LongInt' has eight bytes instead of four.) So you have to replace `0..47' by `0..127', and the expected result reads 1..4: the binary decoding of the capacity (3) of the string, like 11000000 00000000 00000000 00000000 5..8: the binary decoding of the current length (2) of the string, like 01000000 00000000 00000000 00000000 9..10: the binary decoding of the ascii-code of the characters in the string, like 10000010 01000010 11..12: some 16 random bits 01010100 00000000 13..16: the 32-bit decoding of the integer variable, like 10010000 00000000 00000000 00000000 Remarks: * Intel processors store the least-significant byte first ("little-endian"), so `9' becomes 10010000 0 0 0, not 0 0 0 10010000. The Mac, AFAIK, has a 68k processor which does it vice versa ("big-endian"). * Recent beta versions of GPC reserve one additional byte in each string for appending a `chr ( 0 )' character for sake of compatibility to C - which is not yet used. In future versions, byte 11 will be zero, and only byte 12 will have random bits when the length of the string is `2'. (That's why the size of the string is 12, not 11.) !! You have discovered a bug in GPC: The compiler had forgotten to store the capacity of the string in the variant record. I will fix it as soon as possible - thanks for the report. To work around, manually assign `x.rec.name.capacity:= 3' before you assign a value to `x.rec.name'. !! You have discovered yet another bug in GPC: Accessing the packed array does not work correctly. Below is a patch to `types.c' which fixes the problem for Linux on the PC. (It may cause alignment problems on the Alpha; I will have to check ...) * It is planned for gpc-2.2 to implement that sort of strings used in Borland Pascal and Think Pascal as a new data type `ShortString'. > Does anybody know, what I did wrong ? Nothing. :-) Only one hint: Always avoid doing assumptions on the internal representation of data in your programs, if possible. > Is it possible in another way to access > and change some bits of a string of any other variable with the use of GPC ? Yes: GPC implements Borland's `absolute' directive: Var Name: String ( 3 ); (* Extended Pascal wants `String ( 42 )', *) (* not `String [ 42 ]'. *) Bits: packed array [ 0..95 ] of Boolean absolute Name; This means that `Name' and `Bits' share the same location in memory. But we do not want to rely on the internal structure of `Name', thus it is cleaner to write Bits: packed array [ 0..BitSizeOf ( Name ) - 1 ] of Boolean absolute Name; Then `Bits' will always have the correct size. Other methods to access bits are * Sets. A set is in fact an array of bits, indexed with the element type. Those bits whose indices are elements of the set are 1, the others are 0. * Bit masking. You can apply the (bitwise) `and' operator to a pair of integer values. If you want, for instance, to check whether the third bit (i.e. bit number 2) in a given integer `k' is set, you can write: if k and 8 = 0 then ... To test the `n + 1'th bit (i.e. the bit number `n') use if k and ( 1 shl n ) = 0 then ... with `shl' being the "shift left" operator. This is how packed arrays of Boolean as well as sets work internally. Greetings - and thanks for the bug reports, 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] 8< ---- gpc.diff ------------------------------------------------------------- To apply this patch, cd to the GPC source directory (a subdirectory `p' of the GCC source directory) and type patch -p1 < gpc.diff --- ../../gpc-971112/p/types.c Thu Nov 6 17:52:11 1997 +++ types.c Sun Nov 16 19:13:46 1997 @@ -1895,23 +1908,26 @@ * shift operations here. */ unsigned HOST_WIDE_INT imask; + tree long_type = TREE_INT_CST_LOW (bits) >= HOST_BITS_PER_WIDE_INT / 2 + ? long_long_unsigned_type_node + : unsigned_type_node; tree mask; - tree host_bits_per_wide_int = - build_int_2 (HOST_BITS_PER_WIDE_INT, 0); - tree ull_ptr = build_pointer_type (long_long_unsigned_type_node); + tree half_bits_per_long_type = build_int_2 (TYPE_PRECISION (long_type) / 2, 0); + tree half_bytes_per_long_type = build_int_2 (TYPE_PRECISION (long_type) / (2 * BITS_PER_UNIT), 0); + tree ull_ptr = build_pointer_type (long_type); tree offset = build_binary_op (FLOOR_MOD_EXPR, index, - host_bits_per_wide_int, 0); - index = build_binary_op (TRUNC_DIV_EXPR, index, - host_bits_per_wide_int, 0); + half_bits_per_long_type, 0); + index = build_binary_op (FLOOR_DIV_EXPR, index, + half_bits_per_long_type, 0); imask = ((unsigned HOST_WIDE_INT) ~0) - >> (HOST_BITS_PER_WIDE_INT - TREE_INT_CST_LOW (bits)); + >> (TYPE_PRECISION (long_type) - TREE_INT_CST_LOW (bits)); mask = build_int_2 (imask, 0); mask = build_binary_op (LSHIFT_EXPR, mask, offset, 0); var_access = convert_array_to_pointer (var_access); var_access = convert (string_type_node, var_access); var_access = build_binary_op (PLUS_EXPR, var_access, build_binary_op (MULT_EXPR, index, - host_bits_per_wide_int, 1), 1); + half_bytes_per_long_type, 1), 1); var_access = convert (ull_ptr, var_access); var_access = build_indirect_ref (var_access, "packed array access"); var_access = build_binary_op (BIT_AND_EXPR, var_access, mask, 1);

1 0

Re: getting at the bits [was: (null)]
by Kevin A. Foss 16 Nov '97

16 Nov '97

Christian Bockermann wrote: >Hello everyone ! Hiya. >var > x : RECORD > CASE Boolean OF > False :( > rec:Record > name : String[3]; > number : integer; > end); > true :( > field:packed array [0..47] of boolean > ); > end; If you do a writeln(sizeof(x)); you'll find GPC is making this a lot longer than 6 bytes long -- it shows up as 16 on my system. I think this has to do with the other fields that GPC uses for the string type (e.g. .Capacity), although that doesn't explain all of the length and even with a 128 bit field I don't see much. I'm sure someone else (Peter?) knows what is going on. I was able to get the code to do something intelligible If I change your record definition to: [...] rec: packed record name : packed array[0..2] of char; number : integer(16); [...] field:packed array [0..39] of boolean and fixed the loop to go through 40 bits. I get a nice little 5 byte structure and the output is: binary decoding : 10000010 01000010 00000100 10010000 00000000 Note that the end of the byte is different as the left most bit is the 1 bit -- gpc fills in a space for the undefined character, and you loose the length field because I used a standard Pascal string. Hope that is of some help, -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

None
by chris＠bockermann.ping.de 16 Nov '97

16 Nov '97

Subject: variant records and packed arrays To: gpc(a)hut.fi Date: Sun, 16 Nov 1997 13:12:13 +0100 (MET) From: "Christian Bockermann" <chris(a)bockermann.ping.de> X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1971 Hello everyone ! I have a little question concerning variant records and packed arrays. In schoolwe wrote a little program with a declaration part like this : var x : RECORD CASE Boolean OF False :( rec:Record name : String[3]; number : integer; end); true :( field:packed array [0..47] of boolean ); end; The consequence was that the record (rec) and the array (field) were settled in the same area in memory. So this area could be interpreted as a field of bits or a record of a string an an integer variable. This was done on a Mac with Think Pascal :-(, but I'm unable to do something like this on my Linux-Box. The rest of my program looks like this : procedure print_out; var i :integer; begin write('binary decoding :'); for i:=0 to 47 do begin if x.field[i] then write('1') else write('0'); if i MOD 8 = 7 then write (' '); end; end; begin x.rec.name:='AB'; x.rec.number:=9; writeln(x.rec.name, x.rec.number); print_out; end. So I expected the output to be 1.) the binary decoding of the length of the string, like 00000010 2,3.) binary decoding of the ascii-code of the characters in the string, like 01000001 01000010 4.) some 8 random bits 01010101 or something similar... 5.) the 16-bit decoding of the integer variable, like 00000000 00001001 The output I get is : 1.) 2.) 3.) 4.) 5.) 6.) binary decoding :00000000 00000000 00000000 00000001 10000000 00000000 Does anybody know, what I did wrong ? Is it possible in another way to access and change some bits of a string of any other variable with the use of GPC ? If anybody can help ... THANKS a lot !! -- Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key) -- Bis denn, Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

1 0

`case' statments: `default' and `others'
by Peter Gerwinski 15 Nov '97

15 Nov '97

Hello, everybody! I am currently fixing the bug with `otherwise' in `case' statements. While the ISO 10206 Extended Pascal standard wants case foo of (* 1 *) bar: writeln ( 'foobar!' ); otherwise write ( 'The answer is: ' ); writeln ( answer ); end (* case *); GPC implemented case foo of (* 2 *) bar: writeln ( 'foobar!' ); otherwise: begin write ( 'The answer is: ' ); writeln ( answer ); end (* otherwise *); end (* case *); which is simply wrong. Okay - when I fix it, does anybody want to keep an optional colon after `otherwise'? Or after `else' in the Borland syntax? (I would prefer if *not*.) I also found `default' and `others' as synonyms for `otherwise' which I would like to remove. May I? Or are they needed for compatibility with some Pascal compiler I am not aware of? If so, what is the syntax? Example 1 or 2 above? While I am on it, what about removing `&' as an address operator and to keep only the BP-compatible `@'? Please post your opinions here. Thanks, 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: probs compiling current beta GPC
by Peter Gerwinski 15 Nov '97

15 Nov '97

According to Clyde Meli: > > Now I attempted to compile the beta but I ran into problems again, this time > with parse.y (I've recompiled bison again - version 1.25 - from what I tried > to check I found it should be the latest version) and using the new > parse.h which you gave me. Now I got the following errors: > [...] > parse.y:752: warning: implicit declaration of function `pedwarn' > parse.y:755: warning: implicit declaration of function `initialize_module' > parse.y:756: `current_module' undeclared (first use this function) This looks for me as if your `parse.c' does not include the correct header files. Maybe your `bison' behaves different than mine and stores `#include's in `parse.h' rather than `parse.c', so my version of `parse.h' does not work with your `parse.c'? To proceed, I suggest to `mv' away `parse.c' and my `parse.h' and to reconstruct both with your `bison'. Also check which files your `parse.c' does `#include'. Hope this helps a little, :-/ 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: Type conversions
by Peter Gerwinski 15 Nov '97

15 Nov '97

According to Hans Ecke: > > I think I was a little bit lazy in my question. Of course I meant: What is > the schema of type conversion between the members of the ordinal,real and > string type familys. I.e. what happens internally and what does the > compiler ... This is a nontrivial question. The complete answer is the function `convert_for_assignment()' in the GPC source file `gpc-typeck.c'. When passing parameters, other conversions are made, see the function `convert_arguments()', also in `gpc-typeck.c'. Just a few general guidelines: - Strings are truncated, where necessary. - According to Extended Pascal, char variables may get a string value assigned :-( which results in the assignment of the first character or a space in case of the empty string. (GPC warns about this.;-) - If you assign a value to a variable of a compatible, but shorter type, *no* run-time checks are currently done to ensure that the result will fit in the variable. This is planned for gpc-2.2. > ... if there are lines like > > var i:integer; > l:longint; > > r:real; > e:extended; > > s:string(255); > p:pchar; > begin > i:=l; Silently truncated; overflows are not caught. > e:=r; Works without problem. (`Extended' may also be called `LongReal'.) > p:=s; This works if you enable extended syntax (*$X+*). Then the pointer will point to the first character in the string; the capacity and the length of the string are ignored. Please not that GPC does *not* (yet!;-) automatically append a `chr ( 0 )' to the string. > end. 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

← Newer
1
2
3
4
5
6
7
8
...
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