Gpc October 1997

gpc@gnu.de

31 participants
158 discussions

Re: Does GPC have structured constants ?
by Peter Gerwinski 30 Oct '97

30 Oct '97

According to richard.kerry(a)quantel.com: > > Does GPC have structured constants, as found in Oregon and Vax Pascal ? Yes, do it like this: Type ThreeNumbersType = record a, b, c: integer; end (* ThreeNumbersType *); Const FirstConst: ThreeNumbersType = ( 1, 2, 3 ); SecondConst: ThreeNumbersType = ( a: 42; b: 64; c: 96 ); > Here's hoping the answer is "yes, do it like this ..." 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: Sizeof LongInt
by Peter Gerwinski 30 Oct '97

30 Oct '97

According to Jesper Lund: > > Is code written using the portable `Integer ( 64 )' as efficient as code > using the type `LongInt' (assuming that LongInt is 64-bit), or is there some > performance loss? In short: There is no performance loss. :-) In long: If `LongInt' is 64-bit, then `Integer ( 64 )' is exactly the same as `LongInt'; if, on another machine, `Integer' is 64-bit, then `Integer ( 64 )' is exactly the same as `Integer'. A loss of performance can only occur on machines without registers whose width is a divisor of 64 - which I have never seen. 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: Sizeof LongInt
by Peter Gerwinski 29 Oct '97

29 Oct '97

According to Jesper Lund: > Is Sizeof (LongInt) = 8 on *all* systems supported by GPC? Not guaranteed. It might be 16 on some systems. > I am asking this because writing a good pseudo-random number generator is a > lot easier (transparent) and more efficient (execution speed) if a 64-bit > Integer is available. Use `Integer ( 64 )' which is guaranteed (to the extend of the GPL;-) to have 64 bits. 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: gpc on Linux
by Peter Gerwinski 29 Oct '97

29 Oct '97

According to Tomaz kolenko: > $ gpc -v > gpc version 2.0(2.7.2.1) I meant: `gpc -v yourprogram.pas'. ;-) But never mind ... > Thank you for reply. Probably I should tell that I use Debian Linux. Yes, that's an important information. This problem already was discussed on this list in March 1997. (You can look it up from the archives which are reachable from http://home.pages.de/~GNU-Pascal/support.html.) To symlink `libgpc.so -> libgpc.so.2' in `/usr/lib' was reported to work. Hope this helps, Peter PS: Better always mail things like this through the GPC mailing list because there might be others on this list having the same problem. 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: Portable random numbers
by Peter Gerwinski 29 Oct '97

29 Oct '97

According to Jesper Lund: > > Is there a well-defined standard for the ANSI, GNU or BSD `rand' function? > If so, where can I find it? The only thing I have is the source code for > rand in my DJGPP C library. What I have seen is the source code of the BSD random number generator. It contains kind of scientific paper about why these are good random numbers. BTW, to initialize the actual random number generator - and only for this purpose -, they use yet another, very primitive random number generator which has about the same quality as that of BP ... ;-) 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 The African Chief 29 Oct '97

29 Oct '97

Bill Currie wrote: > > On 27 Oct 97 at 8:50, Frank Heckenbach wrote: > [...] > > - After calling an I/O function, if {$I+} is turned on, the calling > > program > > must check InOutRes. The code to be generated (perhaps you've > > already done so) would look like "if InOutRes<>0 then _p_ioerror;" > > where _p_ioerror will be a RTS function I can provide. (The check > > "if InOutRes<>0" could also be done in the function (like in BP!), > > but that's inefficient, because the function has to be called > > after each I/O operation then.) > > Actually, that's almost exactly what my mods do. If IO checking is > enabled ( {$I+} ), a proceedure taking no parameters is called that > would check the InOutRes state (though I used a different name) and > if it's set dumps a dirty message and aborts the program. For compatibility with BP, you would need to call the variable "InOutRes", and it should be exported, so that programmers can set it manually if they want (this feature of BP might be considered to be a bug by some, but I have found great use for it ...). 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 1

Re: Trapping I/O runtime errors in GPC
by Frank Heckenbach 29 Oct '97

29 Oct '97

Bill Currie wrote: > > I might modify this procedure a bit to use the (current) standard > > way of handling runtime errors (_p_generic and such), but this > > shouldn't be a problem. However, if you could move the check into > > the program, this would gain some efficiency. > > Shouldn't be too difficult. I'll just have to figure out which > expression tree's I need (a call is easier to build, that's all). Yes, I guess so... BTW: When I've done all the RTS work, I'll send you a list of all the RTS functions that need checking. Or did you already figure them all out? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

Re: Portable random numbers
by Jesper Lund 29 Oct '97

29 Oct '97

Jesper Lund wrote: > >Is there a well-defined standard for the ANSI, GNU or BSD `rand' function? >If so, where can I find it? The only thing I have is the source code for >rand in my DJGPP C library. I found the code for the BSD random number function (it was in another subdirectory of /djgpp/src/ than the ANSI `rand' function). Jesper Lund

1 0

Sizeof LongInt
by Jesper Lund 29 Oct '97

29 Oct '97

Is Sizeof (LongInt) = 8 on *all* systems supported by GPC? I am asking this because writing a good pseudo-random number generator is a lot easier (transparent) and more efficient (execution speed) if a 64-bit Integer is available. Regards, Jesper Lund

1 0

Re: Portable random numbers
by Peter Gerwinski 29 Oct '97

29 Oct '97

According to Jesper Lund: > > >PROCEDURE Randomize; > >BEGIN > > SRand(GetPID); > > RandSeed:=Rand > >END; > > I don't see how this should emulate the Randomize procedure in Borland > Pascal. According the info docs for my C library, getpid returns the unique > process number for the program running on the system. If you call getpid > twice in the same program, you get the same integer. Why not compute a seed > from the system time (somehow), as Borland Pascal does? If the sysetm time is always available, I agree. OTOH, `Randomize' should never be used twice in the same program! I know someone who tried to get "even more random" numbers by calling `Randomize' before each sequence of calls to `Random', but the calculations in between were so fast that the time did not change between two `Randomize's. As a result, the random numbers were the same in all sequences - with Borland Pascal. > That is, if we need a Randomize procedure at all? My C library (DJGPP) > doesn't have such a beast. Ok, there is Borland compatibility .... > > I use random numbers a great deal in my work (statistical simulations), and > in most cases (if not all) I specify the seed myself, since this is the only > way of gettting reproducible results. [...] For scientific application I agree. For games and such, that little bit of "true random" is a must. > The following piece of code represents a widely used procedure for generating > uniform random numbers (reals between 0.0 and 1.0), but it could easily be > changed to generating integers between 0 and 2^31-1 (just modify the last > line in RanUni). If the quality of these random numbers can compete with those produced by the GNU or BSD C library, and if there are no problems with copyright, I would be happy to incorporate this code into GPC's run time library and to implement BP's `Randomize' and `Random' for GPC on top of that (perhaps with Frank's unit as a replacement for those who specify `--borland-pascal' for 100% compatibility;-). 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

Jump to page:

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