Gpc

gpc@gnu.de

5400 discussions

Re: `case' statments: `default' and `others'
by richard.kerry＠quantel.com 17 Nov '97

17 Nov '97

Peter Wrote: According to richard.kerry(a)quantel.com: > [`begin/end' after `otherwise' ...] > [...] > Oh, and the lack of trailing colon is easier as that's the way Oregon has > it. Again, if it's optional it doesn't matter. Just to be sure that I have understood everything correctly: It is okay for you if we drop the colon after `otherwise' (i.e. forbid it) as long as we do not forbid a `begin/end' pair after `otherwise'? ------- That is correct. Oregon has no colon, and has 'statement' not 'statement-list' ie. it requires begin/end if there is more than one statement. It always has the Otherwise after all the cases. Richard.

1 0

Dodgy email
by richard.kerry＠quantel.com 17 Nov '97

17 Nov '97

Does anyone recognize any of the names in the following extract : ------------------------- Could not deliver Message to ------------------------- CN=??r J Rodriguez/O=almenna kerfisfraedistofan@almenna kerfisfraedistofan User ??r J Rodriguez/almenna kerfisfraedistofan@almenna kerfisfraedistofan not ------------------------- I am getting this whenever I send a message to the mailing list. I am told that the names are not in the list explicitly. Does anyone have them in a sub-list ? Or recognize them from anwhere else ? Richard.

1 0

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

17 Nov '97

According to richard.kerry(a)quantel.com: > [`begin/end' after `otherwise' ...] > [...] > Oh, and the lack of trailing colon is easier as that's the way Oregon has > it. Again, if it's optional it doesn't matter. Just to be sure that I have understood everything correctly: It is okay for you if we drop the colon after `otherwise' (i.e. forbid it) as long as we do not forbid a `begin/end' pair after `otherwise'? So it will be correct to write case foo of 1: writeln ( 'foobar!' ); otherwise writeln ( 'foo?' ); writeln ( 'bar!' ); end (* case *); as well as case foo of 1: writeln ( 'foobar!' ); otherwise begin writeln ( 'foo?' ); writeln ( 'bar!' ); end (* otherwise *); end (* case *); but GPC will reject case foo of 1: writeln ( 'foobar!' ); otherwise: writeln ( 'foo?' ); writeln ( 'bar!' ); end (* case *); or case foo of 1: writeln ( 'foobar!' ); otherwise: begin writeln ( 'foo?' ); writeln ( 'bar!' ); end (* otherwise *); end (* case *); or case foo of otherwise: begin writeln ( 'foo?' ); writeln ( 'bar!' ); end (* otherwise *); 1: writeln ( 'foobar!' ); end (* case *); 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: `case' statments: `default' and `others'
by richard.kerry＠quantel.com 17 Nov '97

17 Nov '97

Peter Wrote : 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*.) --------- surely, since you need begin/end in : case foo of (* 1 *) bar: begin writeln ( 'foobar!' ); writeln ( 'again' ); end; you should need them in : otherwise: begin write ( 'The answer is: ' ); writeln ( answer ); end (* otherwise *); Having said that, it doesn't matter unless you explicitly stop them being usable there, but since you'd be making it accept statement-list rather than statement it'll still be usable. (I have three-hundred plus modules to convert so I look very carefully at suggestions to restrict the syntax accepted.) Oh, and the lack of trailing colon is easier as that's the way Oregon has it. Again, if it's optional it doesn't matter. -------------- Peter Wrote : I also found `default' and `others' as synonyms for `otherwise' which I would like to remove. what about removing `&' as an address operator and to keep only the BP-compatible `@'? -------------- These are ok by me as our Oregon-to-gpc translator can do these either way, and Oregon uses Otherwise. Richard.

1 0

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

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