Gpc January 1998

gpc@gnu.de

23 participants
48 discussions

Near pointers...
by Orlando Llanes 16 Jan '98

16 Jan '98

I came across some DJGPP code and tried it in Pascal and it works! 3 lines and you can set pointers directly and use them without crashing. Works great especially for graphics since you won't need to set the segment registers :) The C code was written by Emmanuel Lagare with help by Brennan Underwood. Here's the GPC code: TYPE TDWord = Cardinal(32); TWord = Cardinal(16); PByte = ^TByte; TByte = Cardinal(8); TDPMIRegs = RECORD EDI, ESI, EBP, Rsvd, EBX, EDX, ECX, EAX : TDWord; Flags, ES, DS, FS, GS, IP, CS, SP, SS : TWord; END; VAR Foo : PByte; DJBase : ASMName '__djgpp_base_address' TDWord; PROCEDURE djgpp_nearptr_enable; ASMName '__djgpp_nearptr_enable'; PROCEDURE djgpp_nearptr_disable; ASMName '__djgpp_nearptr_disable'; PROCEDURE SimRMI( aInt : TWord; VAR aRegs : TDPMIRegs ); ASMName '__dpmi_int'; VAR Regs : TDPMIRegs; PROCEDURE SetMode( aMode : TWord ); BEGIN Regs.EAX := aMode; SimRMI( $10, Regs ); END; BEGIN djgpp_nearptr_enable; TDWord( Foo ) := $A0000 + (-DJBase); SetMode( $13 ); asm( 'movl $0x0F0F0F0F, %eax' ); asm( 'movl %0, %%edi' : '=m' (Duh) ); asm( 'addl $4000, %edi' ); asm( 'movl %eax, (%edi)' ); ReadLn; SetMode( 3 ); djgpp_nearptr_disable; END. See ya! Orlando Llanes "Hey, we all did the drug thing, we all did the money thing, and eventually you find out that none of that stuff fixes anything, and we have nowhere else to go except to evolve spiritually and intellectually" -- Meredith Brooks "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve.com/homepages/Monkey414

1 1

Re: gpc on a floppy
by Peter Gerwinski 16 Jan '98

16 Jan '98

Hi! According to Paolo M. Pumilia: > Hi pascal-experts, > I would like to put the essential files of gpc for dos > on a single floppy disk. Is it possible? Which files to pick up? For what system? On a generic UNIX system, type `make pascal.bindist' after having compiled GPC. This will create a binary distribution `.tar.gz' archive with all the essential files of GPC. On DOS or OS/2 with DJGPP or EMX, the binary distribution of the Pascal compiler itself fits on a single floppy. However, you also need the DJGPP or EMX development environment. If you already have that installed - fine, then the GPC binary distribution fits your needs. Otherwise you will need 6-10 floppies to carry all important development tools. (See the GPC FAQ list and the DJGPP FAQ list for information which parts are needed for Pascal.) Hope this helps, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

gpc on a floppy
by Paolo M. Pumilia 15 Jan '98

15 Jan '98

Hi pascal-experts, I would like to put the essential files of gpc for dos on a single floppy disk. Is it possible? Which files to pick up? Thank you Paolo Pumilia Since i did not subscribe to the list, please reply also to pumilia(a)mbox.est.it -- --- CSTC - -- --- CSTC -

1 0

Just had to say so...
by Orlando Llanes 15 Jan '98

15 Jan '98

I LOVE THE GPC COMPILER!!!! I know some of you already know this, but I just have to say that GPC is an extremely powerful compiler!!!! :) Keep up the great work GPC Team!!! See ya! Orlando Llanes "Hey, we all did the drug thing, we all did the money thing, and eventually you find out that none of that stuff fixes anything, and we have nowhere else to go except to evolve spiritually and intellectually" -- Meredith Brooks "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve.com/homepages/Monkey414

1 0

Re: gpc 2.0 Failing
by Peter Gerwinski 14 Jan '98

14 Jan '98

Hi! According to Phillip Bruce: > [...] > do gcc -c -o $i -g -O -D`basename $i .o` -I../../gcc-2.7.2.3 > -I../../gcc-2.7.2.3 -I../../gcc-2.7.2.3/config -I. ./rts-zmath.c;\ > done > gcc: Internal compiler error: program cc1 got fatal signal 6 This is a problem with GCC, not with GPC. To work around this, try to compile `libgpc.a' without debugging information and/or without optimization: make CFLAGS="-O" libgpc.a make CFLAGS="" libgpc.a Good luck, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

GCC 2.8.0 has been released
by Richard Kenner 14 Jan '98

14 Jan '98

gcc-2.8.0.tar.gz, 8,477,747 bytes, is now available on prep.ai.mit.edu and all the usual mirror sites. [snip snip] New features for Intel x86 family: Add scheduling parameters for Pentium and Pentium Pro. Support stabs on Solaris-x86. Intel x86 processors running the SCO OpenServer 5 family. Intel x86 processors running DG/UX. Intel x86 using Cygwin32 or Mingw32 on Windows 95 and Windows NT. ^^^^^^^ Yeah! :-) -------------------------------------- > My current development GPC passes all PVS conformance tests for ISO-7185 > Standard Pascal level 0 and (NEW!) level 1 but two minor ones. My idea > is to fix these, make the final beta and release gpc-2.1 even if there > are some remaining known bugs. (An incomplete list of those bugs that > have prevented me from releasing gpc-2.1 up to now follows below.) > > Of course, this plan implies that we must upgrade from gcc-2.7.2.x to > gcc-2.8.0 ASAP. I think it is reasonable to continue support for > gcc-2.7.2.x as long as this works without too much effort. > > Any comments? > 1. We did GPC ports based on cygwin32/b18 sources and EGCS before; but failed to maintain them (and never publicly announced them). 2. In an attempt to build win32 GPC's, I tried two routes: extract win32 support from gcc-2.8 betas, plug that in gcc-2.7.2.x sources and build GPC based on that, and port GPC to pre-gcc-2.8. I never fixed the segfaults in the 2.7.2.x based win32 compilers at higher optimization levels, so they were never made public. I have not done (pre)-2.8 based GPC's for the last six months or so. I am willing to do the 2.8 port once more, but only if we do maintain it this time. I am finishing up a new series of mingw32 GCC-2.8 based tools as we speak; the www pages will be updated this weekend. By now I'm pretty familiar with GCC2 sources; and if we are cautious, this GPC could run on top of EGCS just as well. Greetings, JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

gpc 2.0 Failing
by Phillip Bruce 14 Jan '98

14 Jan '98

Hi, I like to know is anyone else getting the same problem I am. I'm running gcc-2.7.2.3 on Solaris 2.6 on PC platform. rts-bind.c for i in p_ARCTAN.o p_SQRT.o p_LN.o p_EXP.o p_SIN.o p_COS.o p_POW.o p_EXPON.o; \ do gcc -c -o $i -g -O -D`basename $i .o` -I../../gcc-2.7.2.3 -I../../gcc-2.7.2.3 -I../../gcc-2.7.2.3/config -I. ./rts-math.c;\ done touch math-stamp for i in z_ARCTAN.o z_SQRT.o z_LN.o z_EXP.o z_SIN.o z_COS.o z_POW.o z_EXPON.o p_POLAR.o p_ARG.o; \ do gcc -c -o $i -g -O -D`basename $i .o` -I../../gcc-2.7.2.3 -I../../gcc-2.7.2.3 -I../../gcc-2.7.2.3/config -I. ./rts-zmath.c;\ done gcc: Internal compiler error: program cc1 got fatal signal 6 gcc: Internal compiler error: program cc1 got fatal signal 6 gcc: Internal compiler error: program cc1 got fatal signal 6 gcc: Internal compiler error: program cc1 got fatal signal 6 gcc: Internal compiler error: program cc1 got fatal signal 6 gcc: Internal compiler error: program cc1 got fatal signal 6 gcc: Internal compiler error: program cc1 got fatal signal 6 gcc: Internal compiler error: program cc1 got fatal signal 6 gcc: Internal compiler error: program cc1 got fatal signal 6 gcc: Internal compiler error: program cc1 got fatal signal 6 make[1]: *** [zmath-stamp] Error 1 make[1]: Leaving directory `/usr/local/gpc-2.0/rts' make: *** [rts/libgpc.a] Error 2 -- ************************************************************************** **** Phillip B. Bruce This is who I am! ***** **** http://www.jps.net/pbbruce My Web Site ***** **** pbbruce(a)jps.net My personal Email Address ***** **************************************************************************

1 0

Re: Frac/Int problem - patch for GPC
by Peter Gerwinski 12 Jan '98

12 Jan '98

According to Kevin A. Foss: > I was trying the latest alpha and trying to get the new > int/frac functions to work, however the first piece of code I tried > caused gpc to dump core :( Sorry - my fault! A patch to the latest alpha GPC which fixes this problem (and another one related to operators defined in Units) follows below. Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/ 8< -------------------------------------------------------------------- Changes for gpc from gpc-980106. Changes in files you can reconstruct with Bison, etags, makeinfo, and TeX have been omitted. Some of these files are updated just by building the compiler. You can update the rest of these files by executing this command make TAGS info dvi -f Makefile.in in the directory of GPC sources, provided the necessary tools (etags, makeinfo, TeX and texi2dvi) are installed. To apply these diffs, go to the directory gpc-980106 and use the command patch -p1 feeding it the following diffs as input. Then rename the directory to gpc. diff -r -U3 -N -x *.o -x *.log -x *.old -x Makefile -x config.cache -x config.status -x gpc-version.c -x *parse.c -x *parse.h -x gpc-gperf.h -x TAGS -x gpc.?? -x gpc.??s -x gpc.aux -x g?c.info* -x gpc*.html -x *.dvi -x *.toc -x *.html -x INSTALL -x FPKvsGNU -x specs -x core -x version -x rts-version.c -x rts-config.h -x gpc -x gpc-cpp -x gpc1 -x libgpc.a -x config.h -x b[i,c]-* -x hconfig.h -x tconfig.h -x insn-*.[c,h] -x options.h -x specs.h -x stamp* -x tm.h -x gen* -x stage[1-4] -x include -x ?++* -x cc1 -x cccp -x cpp -x enquire -x float.h* -x gfloat.h* -x multilib.h -x lib*.a -x underscore.c -x xg?c -x xlimits.h -x site.exp -x *.bak -x *.swp -x gcc-2.7.2.2.patch -x *.aux -x *.cp -x *.cps -x *.ky -x *.kys -x *.gdt -x *.gpr -x *.gpi -x gpc-config.h -x *.orig gpc-980106/p/ChangeLog gpc/p/ChangeLog --- gpc-980106/p/ChangeLog Tue Jan 6 20:50:55 1998 +++ gpc/p/ChangeLog Mon Jan 12 14:17:50 1998 @@ -1,3 +1,14 @@ +Mon 12 Jan 1998 12:15 Peter Gerwinski <peter.gerwinski(a)uni-essen.de> + + * rts.c: rts[], build_rts_call(): case ucsd_INT, bp_FRAC: + make `int' and `frac' use Frank's RTS functions rather than + converting the argument to `Integer' and back. + +Sat 10 Jan 1998 12:15 Peter Gerwinski <peter.gerwinski(a)uni-essen.de> + + * module.c: load_tree(): case TYPE_DECL: remember the name of + the type in the *_TYPE node. + Tue 6 Jan 1998 20:00:00 Peter Gerwinski <peter.gerwinski(a)uni-essen.de> * rts.c: rts-read(): pass correct string capacity for diff -r -U3 -N -x *.o -x *.log -x *.old -x Makefile -x config.cache -x config.status -x gpc-version.c -x *parse.c -x *parse.h -x gpc-gperf.h -x TAGS -x gpc.?? -x gpc.??s -x gpc.aux -x g?c.info* -x gpc*.html -x *.dvi -x *.toc -x *.html -x INSTALL -x FPKvsGNU -x specs -x core -x version -x rts-version.c -x rts-config.h -x gpc -x gpc-cpp -x gpc1 -x libgpc.a -x config.h -x b[i,c]-* -x hconfig.h -x tconfig.h -x insn-*.[c,h] -x options.h -x specs.h -x stamp* -x tm.h -x gen* -x stage[1-4] -x include -x ?++* -x cc1 -x cccp -x cpp -x enquire -x float.h* -x gfloat.h* -x multilib.h -x lib*.a -x underscore.c -x xg?c -x xlimits.h -x site.exp -x *.bak -x *.swp -x gcc-2.7.2.2.patch -x *.aux -x *.cp -x *.cps -x *.ky -x *.kys -x *.gdt -x *.gpr -x *.gpi -x gpc-config.h -x *.orig gpc-980106/p/module.c gpc/p/module.c --- gpc-980106/p/module.c Tue Jan 6 20:44:36 1998 +++ gpc/p/module.c Sat Jan 10 12:04:38 1998 @@ -1881,6 +1881,8 @@ #endif DECL_NAME (t) = load_tree (s, depth + 1); TREE_TYPE (t) = load_tree (s, depth + 1); + if (code == TYPE_DECL) + TYPE_NAME (TREE_TYPE (t)) = DECL_NAME (t); DECL_INITIAL (t) = load_tree (s, depth + 1); DECL_CONTEXT (t) = current_function_decl; break; diff -r -U3 -N -x *.o -x *.log -x *.old -x Makefile -x config.cache -x config.status -x gpc-version.c -x *parse.c -x *parse.h -x gpc-gperf.h -x TAGS -x gpc.?? -x gpc.??s -x gpc.aux -x g?c.info* -x gpc*.html -x *.dvi -x *.toc -x *.html -x INSTALL -x FPKvsGNU -x specs -x core -x version -x rts-version.c -x rts-config.h -x gpc -x gpc-cpp -x gpc1 -x libgpc.a -x config.h -x b[i,c]-* -x hconfig.h -x tconfig.h -x insn-*.[c,h] -x options.h -x specs.h -x stamp* -x tm.h -x gen* -x stage[1-4] -x include -x ?++* -x cc1 -x cccp -x cpp -x enquire -x float.h* -x gfloat.h* -x multilib.h -x lib*.a -x underscore.c -x xg?c -x xlimits.h -x site.exp -x *.bak -x *.swp -x gcc-2.7.2.2.patch -x *.aux -x *.cp -x *.cps -x *.ky -x *.kys -x *.gdt -x *.gpr -x *.gpi -x gpc-config.h -x *.orig gpc-980106/p/rts.c gpc/p/rts.c --- gpc-980106/p/rts.c Tue Jan 6 20:44:36 1998 +++ gpc/p/rts.c Mon Jan 12 12:08:06 1998 @@ -82,6 +82,9 @@ { pp_SIN, "sinl", NULL_RTX, NULL_TREE}, { pp_SQRT, "_pp_sqrt", NULL_RTX, NULL_TREE}, + { ucsd_INT, "_p_int", NULL_RTX, NULL_TREE}, + { bp_FRAC, "_p_frac", NULL_RTX, NULL_TREE}, + { p_DISPOSE,"_p_dispose", NULL_RTX, NULL_TREE}, { p_EOF, "_p_eof", NULL_RTX, NULL_TREE}, { p_EOLN, "_p_eoln", NULL_RTX, NULL_TREE}, @@ -1754,67 +1757,6 @@ break; } - case ucsd_INT: - { - /* Calculate the integer part of a real number by converting it - * to the largest possible integer type and back. - * - * If the number is too big to fit in an integer and has a - * precision not bigger than that of the integer, we know that - * it does not have a fractional part. - * - * If the number is too big to fit in an integer but has a - * precision not than that of the integer, we are hosed. - * Maybe we should do a loop then ... - * - * This code is suboptimal anyway, since at least the i386 has - * a single instruction which calculates `int'. @@@@ - */ - INLINE_RTS_LENGTH ("int", 1); - if (code == REAL_TYPE) - { - if (TYPE_PRECISION (type) <= TYPE_PRECISION (long_long_integer_type_node)) - { - tree abs_val = build_unary_op (ABS_EXPR, val, 0); - tree condition = build_binary_op (GT_EXPR, abs_val, - convert (type, TYPE_MAX_VALUE (long_long_integer_type_node)), 0); - retval = convert (type, convert (long_long_integer_type_node, val)); - retval = build (COND_EXPR, type, condition, - val, retval); - } - else - abort (); - } - else - errstr = "argument to `int' must be of real type"; - break; - } - - case bp_FRAC: - { - /* frac ( foo ) = foo - int ( foo ). - */ - INLINE_RTS_LENGTH ("frac", 1); - if (code == REAL_TYPE) - { - if (TYPE_PRECISION (type) <= TYPE_PRECISION (long_long_integer_type_node)) - { - tree abs_val = build_unary_op (ABS_EXPR, val, 0); - tree condition = build_binary_op (GT_EXPR, abs_val, - convert (type, TYPE_MAX_VALUE (long_long_integer_type_node)), 0); - retval = convert (type, convert (long_long_integer_type_node, val)); - retval = build (COND_EXPR, type, condition, - val, retval); - } - else - abort (); - retval = build_pascal_binary_op (MINUS_EXPR, val, retval); - } - else - errstr = "argument to `frac' must be of real type"; - break; - } - case p_SUCC: { /* rts_inline */ @@ -3027,6 +2969,14 @@ rval = double_type_node; fpar = ptype_double; } + break; + } + + case ucsd_INT: + case bp_FRAC: + { + rval = long_double_type_node; + fpar = ptype_long_double; break; }

1 0

Re: gpc linker problems
by Peter Gerwinski 11 Jan '98

11 Jan '98

Hello! According to Rod Evans: > If anyone can help with this, would you please email me direct since I'm > not subscribed to the mailing list. > > The problem: general linker problems in gpc 2.0. > eg. > gpc -v -o fibonacci fibonacci.pas > Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.7.2.1/specs > gcc version 2.0(2.7.2.1) > [...] This looks as if your `gcc.c' were not patched for GPC but the original GCC version. Thus your `gpc' does not recognize the extension `.pas' as Pascal source but takes it as linker input. > 1) The first 'make' had a VPATH problem which caused it to fail for target > gpc1; following the FAQ, I removed those '.o' files from the gcc object > directory. I then got a clean make. Maybe still something went wrong with this - at least for the `gpc' driver program, not for the actual compiler `gpc1'. To solve the problem, recompile `gcc.c' to `gcc.o' and watch whether the `-DGPC' switch is given. For a general solution to the VPATH problem it might help to upgrade to a recent beta version of GPC; see ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/ Hope this helps, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

Frac/Int problem
by Kevin A. Foss 09 Jan '98

09 Jan '98

Hello again, I was trying the latest alpha and trying to get the new int/frac functions to work, however the first piece of code I tried caused gpc to dump core :( program test(output); begin writeln(frac(3.14)); end. As does running frac on a declared const: const r = 3.14; begin writeln(frac(r)); end. It works fine if I run frac across a variable real tho: var r : real VALUE 3.14; begin writeln(frac(r)); end. Similiar results with int(). -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

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 January 1998