January 2017 - Gpc

10206 lexical ambiguity
by Paul Isaacs 24 Jan '17

24 Jan '17

Hello, Am I correct that, without semantic type tie-ins, that the production new-ordinal-type = enumerated-type | subrange-type ; is ambiguous because (a) could be both an enumerated type and the expression for the lower bound of a subrange? Regards, Paul Isaacs

5 9

function-pointer
by Paul Isaacs 23 Jan '17

23 Jan '17

Hello, From ISO spec: production: expression can be variable-access variable-access can be function-identified-variable function-identified-variable is pointer-function '^' pointer-function is function-access function-access can be entire-function-access entire-function-access is function-designator function-designator is function-name But: function test : boolean; begin test := false; end; procedure test1; begin if test^; end; generates the error "invalid type of argument of '^'" function-identified-variable only appears on the rhs of the variable access production. The expression test^ seems lexically correct. I know I am wrong. But where? How is function-identified-variable used? I really can't understand 6.8.6.4 Function-Identified-Variables of the spec. It sounds like a function-identified-variable is the return value of a pointer function. Is test^ a pointer function? Regards, Paul Isaacs

1 1

Re: type-inquiry
by Waldek Hebisch 23 Jan '17

23 Jan '17

I wrote: > > Paul Isaacs wrote: > > > > On 22/01/17 11:09 AM, Waldek Hebisch wrote: > > > It seems that if you want you can replace type-inquiry by explicit > > > definition. > > > > Hello Waldek, > > > > Thanks for the reply. I just assumed, incorrectly, that type-inquiry was > > a reflective construct of some sort. > > It _is_ a reflective construct. Just most of time you can live > without it. Maybe an example: > > var a : record i : integer end; > > Note that if you write: > > var b : record i : integer end; > > then b will be of different type than a (because each 'record' > introduces entirely new type). You can solve the problem > using named type: > > type t = record i : integer end; > var a : t; > > var b : t; > > Or you can use type-inquiry: > > var b : typeof(a); > > If you can modify declaration of 'a' you probably prefer > first version. But in real life you may be unable to > modify declaration of 'a'... > > Note: in GPC 'typeof' is only implemented for object types > (which are absent in Extended Pascal) so this does not work. Oops. I should write: var b : type of(a); 'typeof' is a Borland Pascal stuff, 'type of' is Extended Pascal. Both are obscure enough that I confused them. -- Waldek Hebisch

1 0

type-inquiry
by Paul Isaacs 23 Jan '17

23 Jan '17

Hello, How is the production type-inquiry used? var p : integer; type q = type of p; How would it be possible that inquiring as to the type of p is useful? Under what circumstances would the type of p not be already known? Even if the type of p were not known, how would q be usable if its type were not fixed? The only reference I can find is in the GNU-Pascal Manual. function CompilerAssert( condition : boolean, result : Anytype ) : type of Anytype; What would be returned? Unless Anytype is restricted to types that CompilerAssert is aware of. Regards, Paul Isaacs

3 4

program parameters
by Paul Isaacs 19 Jan '17

19 Jan '17

Hello, Are program parameters tied in any way to command line parameters? Is it possible to set BindingType.Name from the command line using a program parameter? program( a ... var a : bindable Text; b : BindingType; begin b := Binding( a ); Bind( a, b ); where b.Name has been set from the command line. Thank you, Paul Isaacs

3 3

Re: Gpc Digest, Vol 43, Issue 19
by Oscar Flor 16 Jan '17

16 Jan '17

Thanks You very much Peter... El 16/1/2017 8:00, <gpc-request(a)gnu.de> escribió: > Send Gpc mailing list submissions to > gpc(a)gnu.de > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.g-n-u.de/mailman/listinfo/gpc > or, via email, send a message with subject or body 'help' to > gpc-request(a)gnu.de > > You can reach the person managing the list at > gpc-owner(a)gnu.de > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gpc digest..." > > > Today's Topics: > > 1. Re: rpm available for fedora (Peter) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2017 17:10:55 +0000 > From: Peter <peter(a)pblackman.plus.com> > To: gpc(a)gnu.de > Subject: Re: rpm available for fedora > Message-ID: <52de0911-c796-8df9-e265-2c46a12ce673(a)pblackman.plus.com> > Content-Type: text/plain; charset=utf-8 > > On 13/01/17 15:16, Oscar Flor wrote: > > Hi Pals: > > > > I find on rpm.pbone rpm packages of gpc20070904 for 64 and 32 bits. I > > test it on Fedora 20 and works. I realize that this version of Fedora > > have the gcc 4.8 installed on it, thats have me to think that this is > > not used to compile gpc and make the rpm package. > > > > I will test on newest fedora releases to know if they still work. > > Meanwhile I will learn read about GCC and his tools to try to make a > > compile on newest vesions on GCC. > > > > Best Regards > > > > Oscar Flor > > > > Hi Oscar, > > The build process is well defined here > http://alignment.hep.brandeis.edu/Software/Pascal/Pascal. > html#Compiling%20from%20Sources > > > The Fedora source packages will likely contain extra patches to help > build (with 4.8) the version of GCC that GPC is based on. There may be > other fixes to the Autotools stuff too. > > > Regards, > Peter > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Gpc mailing list > Gpc(a)gnu.de > https://www.g-n-u.de/mailman/listinfo/gpc > > ------------------------------ > > End of Gpc Digest, Vol 43, Issue 19 > *********************************** >

1 0

rpm available for fedora
by Oscar Flor 15 Jan '17

15 Jan '17

Hi Pals: I find on rpm.pbone rpm packages of gpc20070904 for 64 and 32 bits. I test it on Fedora 20 and works. I realize that this version of Fedora have the gcc 4.8 installed on it, thats have me to think that this is not used to compile gpc and make the rpm package. I will test on newest fedora releases to know if they still work. Meanwhile I will learn read about GCC and his tools to try to make a compile on newest vesions on GCC. Best Regards Oscar Flor

2 1

Vectorizing
by Peter 12 Jan '17

12 Jan '17

I've managed to get some Pascal code to vectorize! See attached example. I used GNU Pascal version 20070904, based on gcc-4.3.6. (64bit) Earlier 4.3.x might work, please try it. Caveats; Array to vectorize must start with lower bound zero. Must use While loop (For loop did'nt work). 32 bit Integers not working, floats or 64bit Ints only. gpc -O3 -ftree-vectorizer-verbose=2 av.pas av.pas:19: note: LOOP VECTORIZED. av.pas:0: note: vectorized 1 loops in function. Regards, Peter

1 0

Inlining with gcc 4.x.x (Linux) ?
by Peter 12 Jan '17

12 Jan '17

I've built GPC 3.4.6 and 4.3.6 on Debian Stretch (64bit) Running benchmarks on a Perlin Noise routine I get 3.4.6 5.6 secs 4.3.6 11.0 secs !! The difference seems to be mainly down to a failure of 4.3.6 to inline. Call functions themselves may not take much time but I believe the real problem is that without the subroutines inlined, the main Noise function is no longer a leaf function, and therefore under register pressure. â¦..... a := Lerp (sx, u10, v10); b := Lerp (sx, u11, v11); d := Lerp (sy, a, b); Noise3 := Lerp(sz, c, d); End; This code produces with 3.4.6 { Hard to know where it starts without line numbers ! } addsd %xmm9, %xmm7 addsd %xmm3, %xmm2 subsd %xmm0, %xmm1 subsd %xmm7, %xmm2 mulsd %xmm14, %xmm1 mulsd %xmm14, %xmm2 addsd %xmm0, %xmm1 addsd %xmm7, %xmm2 subsd %xmm1, %xmm2 mulsd %xmm2, %xmm12 movsd %xmm12, %xmm0 addsd %xmm1, %xmm0 ret which is pretty lean & mean. However, with 4.3.6 I get movsd 112(%rsp), %xmm2 movsd 104(%rsp), %xmm1 movsd 48(%rsp), %xmm0 call _p__M0_S5_Lerp movsd 128(%rsp), %xmm2 movsd %xmm0, 152(%rsp) movsd 120(%rsp), %xmm1 movsd 48(%rsp), %xmm0 call _p__M0_S5_Lerp movsd 152(%rsp), %xmm1 movapd %xmm0, %xmm2 movsd 56(%rsp), %xmm0 call _p__M0_S5_Lerp movsd 40(%rsp), %xmm1 movapd %xmm0, %xmm2 movsd 64(%rsp), %xmm0 call _p__M0_S5_Lerp addq $240, %rsp popq %rbx popq %rbp popq %r12 popq %r13 popq %r14 popq %r15 ret ( Stack spills tend to be expensive on [my] AMD processor as the level 0/1 cache isn't that fast. Maybe I have broken my build of 4.3.6 Can anyone else conform the status of inlining on linux x86 with 4.x.x compilers? The simple example from the info file program InlineDemo; function Max (x, y: Integer): Integer; attribute (inline); begin if x > y then Max := x else Max := y end; begin WriteLn (Max (42, 17), ' ', Max (-4, -2)) end. Also does not work for me with 4.3.6. It still produces a call instruction. call _p__M0_S0_Max I recall also that inlining did not work with the official 4.1 Debian package. I was thinking of reporting this as a (Debian) bug a while back, but GPC was then removed from the archive, which made that moot. Going forward, I'm wondering which gcc version to base my builds on. 4.3.6 supports potentially a few more architectures, ARMel PowerPC SH4 and supports the -m32 switch, but a 100% slowdown on the CPU intensive stuff I use the compiler for is too much a penalty for me. >From further tinkering around, I notice that 3.4.6 often inlines even when not asked to do so, whereas 4.3.6 very rarely if ever inlines. Neither compiler seems to obey the inline attribute! Anyone any thoughts on this? Hoping of course that its an easy to fix typo type bug... Regards, Peter B

5 9

GNU Pascal is still kind of alive (was: Extended Pascal)
by Treutwein Bernhard 10 Jan '17

10 Jan '17

Thanks a lot Waldek for: >Actually, this list is out of date. Starting from gpc-20051104 >qualified module import and structured value initializers are supported. >Few other were supported earlier. Current statement (which >AFAICS corresponds to gpc-20051104) is: > >: The Extended Pascal features still missing from GPC >: are set types with variable bounds and discriminated ordinal schema as >: schema discriminants. > Please don't be insulted, I appreciate very much what you are doing for GNU Pascal, but I think your note gives a good impression of the major obstacles for newcomers to gpc. A lot of information is hidden behind the web sites in personal memories. I know of the following sites: http://www.gnu-pascal.de/gpc/h-index.html http://alignment.hep.brandeis.edu/Software/Pascal/Pascal.html http://www.microbizz.nl/gpc.html https://github.com/hebisch/gpc Maybe there are more. Some infos from the brains went to the mailing list and is available in the archive. But it is unclear to me (and I guess others also) which information is still relevant and which is out of date. This is a bit frustrating, but as long as we have only more or less hobbyists working on GNU Pascal, we are out of luck. I do not know who, how, and where the collected and hopefully current information could be concentrated, but I think it would be very good to have a central place ... Peter Gerwinski noted las march a vague chance to have some student working for her/his thesis on GNU Pascal ... -- Bernhard

7 7