Gpc January 1999

gpc@gnu.de

20 participants
34 discussions

Bug in Make-lang.in of gpc-19980830.tar.gz
by beru＠col.bsf.alcatel.fr 26 Jan '99

26 Jan '99

I found a bug in gpc-19980830.tar.gz ( file Make-lang.in ). When i devekkoppe it with VPATH, i have ht message : install-info --info-dir=/users/dhs3/beru/tools/gnu/info /users/dhs3/beru/tools/gnu/info/g77.info rm -f /users/dhs3/beru/tools/gnu/info/gpc.info* ; cd p/doc; for f in gpc.info*; \ do /bin/sh /twdhs3/beru/ws/my_tools/domain_public/code/gnu/compilo/srclib/srcdir/install-sh -c -m 644 $f /users/dhs3/beru/tools/gnu/info/$f; done /bin/sh: p/doc: does not exist make[1]: *** [pascal.install-info] Error 1 make[1]: Leaving directory `/twdhs3/beru/ws/my_tools/domain_public/code/gnu/compilo/srclib/objdir/gcc' make: *** [install-gcc] Error 2 I have analysed the mistake: A short work around : touch gpc.texi in srclib, this provoque the build of gpc.info* in objlib. an another correction possible : Apply this patch : ###################### on directory gcc/p/ ############# --- Make-lang.in.orig Mon Aug 31 03:05:02 1998 +++ Make-lang.in Tue Jan 19 13:01:06 1999 @@ -385,7 +385,8 @@ pascal.install-info: pascal.info -rm -f $(infodir)/gpc.info* ; - cd p/doc; for f in gpc.info*; \ + if [ -d p/doc ]; then cd p/doc; else cd $(srcdir)/p/doc; fi \ + for f in gpc.info*; \ do $(INSTALL_DATA) $$f $(infodir)/$$f; done -chmod a-x $(infodir)/gpc.info* ######################################## EOF ################# Thanks for your jobs.

2 1

RE: how to bootstrap egcs-1.1.1
by kevin.broadey＠ats.uk.eds.com 25 Jan '99

25 Jan '99

> -----Original Message----- > From: Peter Gerwinski [mailto:peter@gerwinski.de] > Sent: 25 January 1999 17:52 > To: kevin.broadey(a)ats.uk.eds.com > Cc: gpc(a)hut.fi > Subject: Re: how to bootstrap egcs-1.1.1 > > > kevin.broadey(a)ats.uk.eds.com wrote: > > > > The "gmake LANGUAGES=c" bombed out trying to make (I guess) > > one of the C++ libraries that comes bundled with egcs, so > > that's not surprising, and it did manage to build the C > > compiler first. > > > > The "gmake LANGUAGES=pascal" bombed out in the same place, but > > again it built the compiler first. > > For me this looks like a problem with C++, not with Pascal. > If you are not going to install the C++ compiler, better use the > egcs-1.1.1.core distribution instead of the full egcs-1.1.1, or > remove the `cp' directory before installing. I think the problem is that I ran "make" in the top-level objdir, so egcs went off and tried to build its associated libraries without having the compiler in place to do the job. Maybe I should have used "make all-gcc" instead. Dunno. But I really do want to install the C++ compiler, so "make bootstrap" looks like the thing I should be doing. > > But the problem is that I now have a compiler built with > > gcc-2.8.1 rather than egcs-1.1.1. So is there some way I can > > do the equivalent of "make bootstrap" without tripping over > > the circular dependency Peter referred to? > > What about `make CC="gcc/xgcc -Bgcc/ -Lgcc/" LANGUAGES=pascal'? I don't think that will help with the "make bootstrap" problem. What I'm trying now is to hack gcc/Makefile to remove "pascal" from LANGUAGES, then added a rule at the end of the "bootstrap" target to do a "make LANGUAGES=pascal" directly. Dirty, but It Should Work (tm). I'll let you know how I get on. > > (BTW, better truncate your lines to make your emails more > readable.;-) Sorry, beaten by M$ Outlook, I'm afraid :-( Cheers Kevin

1 0

ANNOUNCE: gpc-19990118
by Peter Gerwinski 25 Jan '99

25 Jan '99

This is the announcement of GNU Pascal, beta version gpc-19990118 which is now available from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/ . Binaries for various platforms are available in a subdirectory `binary/'. These platforms include: i586-pc-linux-gnulibc1 (gcc-2.8.1 and egcs-1.1.1) alpha-unknown-linux-gnu alphaev56-dec-osf4.0d mips-sgi-irix6.2 sparc-sun-solaris2.6 i386-pc-djgppv201 (MS-DOS) Binaries for more platforms, including i586-pc-linux-gnulibc2, ix86-mingw32 (MS-Windows 9x/NT) and sparc-sun-solaris2.5.1 will follow soon and announced separately. This is intended to be the next-to-last beta release before the release of GPC 2.1. If you have some suggestions for GPC 2.1 that are not yet listed in the GPC To-Do list at http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html, please contact us at the GPC mailing list <gpc(a)hut.fi> without delay. About GNU Pascal ================ The GNU Pascal Compiler (GPC) is part of the GNU compiler family, GNU CC or GCC. It combines a Pascal front-end with the proven GNU C back-end for code generation and optimization. Unlike utilities such as p2c, this is a true compiler, not just a converter. This version of GPC corresponds to GCC version 2.8.1 or EGCS 1.1.1. The purpose of the GNU Pascal project is to produce a Pascal compiler which: 1) combines the clarity of Pascal with powerful tools suitable for real-life programming, 2) supports both the Pascal standard and the Extended Pascal standard as defined by ISO, ANSI and IEEE. (ISO 7185:1990, ISO/IEC 10206:1991, ANSI/IEEE 770X3.160-1989) 3) supports other Pascal standards (UCSD Pascal, Borland Pascal, Pascal-SC) in so far as this serves the goal of clarity and usability, 4) can generate code for and run on any computer for which the GNU C compiler can generate code and run on. The current beta release gpc-19990118 implements Standard Pascal (ISO 7185, level 1), a large subset of Extended Pascal (ISO 10206, aiming for full compliance), is highly compatible to Borland Pascal (version 7.0) with some Delphi extensions, and provides a lot of useful GNU extensions. For more information about GNU Pascal, see http://home.pages.de/~GNU-Pascal/ . Changes since the previous beta release ======================================= Units ----- The main focus in this GPC release is the inclusion of many standard units. Besides a complete set of BP compatibility units -- except the Graph unit (which is currently distributed separately due to its license) and the OOP stuff --, there are some units to make C functionality available for GPC and some new units. BP compatibility units: - CRT: Curses based text screen handling. Compatible to BP's unit, even in a lot of minor details like the values of function key codes. Includes some routines for compatibility with TP5's `Win' unit as well as BP's `WinCrt' and Turbo Power's `TPCrt' units, and some extensions. - Dos: Portable implementation of those routines from BP's unit that are useful to most programs. Those routines that are only meant for access to Dos internals and cannot be implemented in a portable way, have intentionally been left out. - Overlay: Dummy replacement for BP's unit, since GPC doesn't need overlays. - Ports: Access routines for the hardware ports on the x86, as a partial replacement for BP's `Port' and `PortW' pseudo arrays. - Printer: Implementation of BP's interface for Dos (using printer devices) and Unix systems (using printer utilities). Might need porting to mingw32 to use its native printing abilities. - Strings: Almost empty since most of BP's CString routines have been included into GPC's RTS (available by using the `GPC' unit). - System: Portable implementations for BP's more exotic routines which are not built into GPC's RTS (ExitProc, Lo, Hi, Swap, GetDir, HeapError, MemAvail, MaxAvail), and on special request (by setting some defines), also BP compatible integer type sizes and a 100% BP compatible random number generator. - Turbo3: Compatibility unit for BP's TP3 compatibility unit. ;-) - WinDos: Portable implementation of BP's unit, see the comments for the Dos unit. Other units: - DosUnix: A unit, intented to be growing when necessary, to overcome some differences between Dos and Unix systems. Currently features translation of bash style input/output redirections (`foo 2>&1') into `redir' calls for DJGPP (`redir -eo foo') and a way to read files with Dos CR/LF pairs on any system. - GetOpt: Comfortable command line option parsing. - GMP: Interface to the GNU Multiprecision Library to handle integer, rational and real numbers of unlimited size/precision. - GPCUtil: Some utility routines by The Chief, including implementations of some routines from Turbo Power's units for BP. - Internal: Unit which contains declarations for internal RTS routines that are not declared in the `GPC' unit. Only meant for low-level access by people who know what they're doing. - PExecute: Executing processes. Overcomes some of the differences between Dos and Unix systems. - Pipe: Start a child process and write to/read from its Input/Output/StdErr via pipes. Emulated transparently under Dos as far as possible. - RegEx: Matching and replacing text with regular expressions. Some of the units come with demo programs to show their usage that are installed in <prefix>/doc/gpc/demos/ . A few of the units (in particular: CRT, GMP and RegEx) require C libraries. The sources of the libraries, sometimes with small patches when necessary, and binaries for i586-pc-linux-gnulibc1, i386-pc-go32 and sparc-sun-solaris2 are available from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/libs/ . Compiler features ----------------- The new compiler features have concentrated on making it easier to write and use the units. The AutoMake mechanism is now much more reliable than it was, doesn't recompile units unnecessarily any more, and does not require repeating the options, i.e. instead of writing `--foo --bar --baz --automake="--foo --baz --baz"' one can now simply write `--foo --bar --baz --automake'. The following directives, related to units, are now understood: - --unit-path -- search path(s) (can be used multiple times) for units used by a program. - --object-path -- search paths(s) for object, assembler, C, or other external files used by a program. Defaults to the unit path(s). - --unit-destination-path -- the destination path for units compiled by AutoMake. - --object-destination-path -- the destination path for C, assembler or other external files compiled by AutoMake. Defaults to the unit destination path. - --executable-path -- the destination path for executables compiled. - --uses=foo(bar.pas),bar,baz(../baz.pas) -- automatically using units in a program, optionally specifying a source file name. Useful e.g. for maximum BP compatibility to use units like `GPC' and `System' without changing the source code. The unit and object paths default to the directory where the standard units are installed, i.e. <prefix>/lib/gcc-lib/<target>/<version>/units/, so these units are found automatically. Libraries can now be used by a `{$L foo}' compiler directive, just like simple object files, and this directive also works in units (used a lot in the standard units). The compiler pre-defines `__BORLAND_PASCAL__' etc. depending on the dialect option used or `__GNU_PASCAL__' by default if no dialect option was given (besides `__GPC__' as before, regardless of the dialect used). `__OS_DOS__' is pre-defined on Dos-like systems. Other declarations ------------------ Some of the following declarations are built into the compiler, others are declared in the `GPC' unit. - Memory: Addr (B) Assigned (B) CGetMem CFreeMem ConvertFromLittleEndian ConvertFromBigEndian ConvertToLittleEndian ConvertToBigEndian FreeMemPtr GetMemPtr Null (D?) ReAlloc ReverseBytes - Files and I/O: BlockReadLittleEndian BlockReadBigEndian BlockWriteLittleEndian BlockWriteBigEndian DataReady FileName New fields Force, AccessTime, ModificationTime and ChangeTime in the BindingType record. Text files now use internal buffering to speed up reading and writing -- even on operating systems that do good buffering themselves. (B ;-) - Strings: Copy with only 2 arguments SetString (D) StringOfChar (D) A number of new CString routines, including almost all (that weren't already there) of BP's `Strings' unit. (B) The string comparison operators (`=', `>', etc.) now work like in BP by default, and as described in the ISO-10206 Standard in `--extended-pascal' mode or with the `--no-exact-compare-strings' switch. (B) - Date/Time: GetUnixTime IsLeapYear TimeStampToUnixTime UnixTimeToTimeStamp `(B)': BP compatibility `(D)': Delphi compatibility Have fun, The GNU Pascal development team

3 3

Re: __OS_DOS__
by Frank Heckenbach 25 Jan '99

25 Jan '99

Kevin A. Foss wrote: > On Sat, 23 Jan 1999 22:15:55 +0100, Frank Heckenbach wrote: > > >2) __OS_DOS__ is defined in Pascal on Dos like systems (including > > EMX). It is defined automatically and should not (need to) be > > defined by the user. It's used in Pascal parts of the RTS > > (rts/filename.pas [1], e.g. for directory and path separators), > > in some standard units (DosUnix and Printer) and is available to > > user programs (I need it for a few things in my own programs). > > Okay this is more what I was concerned about (GPC's behavior with > __OS_DOS__ defined) and once I get the system working I'll investigate > its effects, my only real issue is that OS/2 can use either / or \ as a > directory separator internally and I don't know if that will mess up > some routines. In fact you can even mix separators within a path. A > quick look at the source doesn't show any problems as most of the > routines in filename.pas are looking at DirSeparators rather than > DirSeparator and the ones using DirSeparator are mostly 'fixing' paths > for the OS -- if I read them correctly. Yes, exactly. The `DirSeparator' char constant is used when appending a slash or converting paths before passing them to libc routines (though this might not even be necessary, I think it shouldn't hurt), and the `DirSeparators' set of char constant is used when checking for directroy separators. Since the situation is the same on DJGPP, I tested it at least moderately. BTW, other units might need some porting as well: CRT needs a curses version, but I suppose either or both ncurses and/or PDCurses should work under OS/2 (probably PDCurses would be preferable for EMX, since it runs under Dos as well), so CRT should work after setting some ifdefs. A few system specific functions (which are not vital, however), can be ported as well, cf. crtdospc.h for the DJGPP version for them. The printer unit needs porting if you want it to use some native printing capabilities of OS/2. (I don't know if there are any, and what they look like, however.) Otherwise, it will currently use the Dos printer device ('lpt1') which might work under OS/2, but perhaps not be optimal, I don't know. The system unit contains specific MemAvail/MaxAvail routines for DJGPP and mingw. If you want to port them to EMX, go ahead, otherwise the unit will just use the portable (but in this case less efficient) replacements. If the shell supports I/O redirections beyond the simple ones that Dos' command.com knows, and their syntax is different from bash's, (like DJGPP's redir utility), the DosUnix unit should be adapted. If accessing I/O ports requires getting special permissions (like under Linux), the ports unit needs adaption. A few other units require C libraries that ought to just be recompiled for EMX. Binaries can then be stored on Agnes together with the other library binaries. Frank PS: Does EMX work again? Last thing I heard was that it didn't work with GCC 2.8.x. Did you fix it, or did EM finally do something about it? -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

3 2

Re: __OS_DOS__
by Frank Heckenbach 25 Jan '99

25 Jan '99

Kevin A. Foss wrote: > The short of it is that I have a working > 19990118 now and once I clean stuff up I should be able to upload the > patches and binaries in the next couple days. Fine. :-) > Another sticky problem was with the OS_DOS code in gpc.c (ironically > considering how this thread started). Basically I dump core when it > reaches 'free (cpp_predefines);' [line 1620 or so] which I don't find > too unreasonable because I didn't think you could free(3) static > globals. Of course the code does work on other systems so maybe it is > just EMX being picky. I just #ifdef'd the line out for EMX and it > compiles now. Indeed it looks like the code tries to free() a constant, and even though it seems to work under Linux, it's not correct, so it should be fixed. Correct, Peter? > There is also a weird looking "If False" block in the > same area which looks like the code is still under construction. I think the currently active version is meant to be the correct one, the other one was a previous attempt which was less efficient, and perhaps had some problems, I don't remember exactly... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Debian gpc-19990118 binaries available.
by Matthias Klose 24 Jan '99

24 Jan '99

The upcoming Debian GNU/Linux 2.1 version includes a gpc package based on 19990118. Currently it's available from the Debian ftp archive and it's mirrors (look for gpc-2.91.60-4 or newer). Currently it's available for i386 only, packages for m68k, alpha, sparc and arm are expected next week on the archives. For more information please see http://www.debian.org/

1 0

Re: ANNOUNCE: gpc-19990118
by Frank Heckenbach 24 Jan '99

24 Jan '99

Kevin A. Foss wrote: > >The compiler pre-defines `__BORLAND_PASCAL__' etc. depending on the > >dialect option used or `__GNU_PASCAL__' by default if no dialect > >option was given (besides `__GPC__' as before, regardless of the > >dialect used). `__OS_DOS__' is pre-defined on Dos-like systems. > > I remember some discussion on the list about this, but never heard what > the final verdict was -- can someone give a brief description of what > is affected when defining __OS_DOS__. I know at one time things like > device names (lptX) and path separators (which I think may be an issue > with EMX) were an issue and I was just wondering if anything else was > altered. Well, I think there are two things to consider. 1) Some C routines in the RTS do some OS dependent stuff (like device names). Since __OS_DOS__ is not available in C, they use a combination of #ifdefs. You might want to check them in rts/{bind,file,pexecute}.c. The former two check for `__EMX__', the latter checks for `OS2' and `__MSDOS__', so they should be OK for EMX. 2) __OS_DOS__ is defined in Pascal on Dos like systems (including EMX). It is defined automatically and should not (need to) be defined by the user. It's used in Pascal parts of the RTS (rts/filename.pas [1], e.g. for directory and path separators), in some standard units (DosUnix and Printer) and is available to user programs (I need it for a few things in my own programs). [1] To see exactly what is affected, please see rts/filename.pas. Users of GPC binaries can look at the GPC unit (gpc.pas) which also contains the constants affected by __OS_DOS__ (just search for `__OS_DOS__' in gpc.pas). Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

New gpc-19990118 binaries available
by Jan-Jaap van der Heijden 23 Jan '99

23 Jan '99

I have made gpc-19990118 binaries available for i386-linux-glibc2 (RedHat 5.2) and i386-mingw32. Both are egcs-1.1.1 based. A word of caution about the mingw32 binary: I'm rearranging my PC's, and I currently don't have a Windows PC to test this compiler, so this one is really Zero Tested(TM). Hopefully I'll have everything up and running again in a few days. A few other random notes about the mingw32 binary: * You need binutils, mingw32 libraries and probably want GDB. These are available from the usual mingw32 ftp sources. * BP compat units have not been ported. If somebody wants to do this, he'll probably have to get pdcurses, which is available from my mingw32 FTP. These pdcurses come in two flavours: a static version and a DLL. It is probably best to use the static version. The DLL version requires __dllimport/__dllexport capabilities in the compiler. GPC/egcs/mingw32 has these, btw. Happy compiling, JanJaap --- GNU mingw32: http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32

1 0

Gnu Pascal
by Yishay 22 Jan '99

22 Jan '99

Is gpc compatible with DEC pascal and can I use it on MS_DOS? thanks, yishay.

2 1

Re: varargs
by Frank Heckenbach 22 Jan '99

22 Jan '99

Russ Whitaker wrote: > on 1/18 you wrote > > ...the varargs functions are intended to be replaced sooner or later > > ok so how about changing some of the .c files to .cpp? > Then you could use c++'s "function overloading" to replace the varargs Nice idea (apart from the fact that I don't like C++ very much ;-), and it might make building GPC more difficult if it depends on a C++ compiler), but it would only work for one of the five varargs functions (_p_string). The others (_p_write etc.) can have an infinite number of combinations of arguments (just like Write etc. in Pascal), which can't be done by overloading. But, as I said, it's not *too* bad since we're planning to simply break up the functions, i.e. instead of: _p_write (f, CODE_FOR_INTEGER, integer_value, CODE_FOR_REAL, real_value, CODE_FOR_WRITELN); the compiler will issue calls to: _p_write_integer (f, integer_value); _p_write_real (f, real_value); _p_writeln (f); This should also be a little bit more efficient at runtime, since the RTS doesn't have to do dispatching... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

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