Gpc December 1999

gpc@gnu.de

26 participants
45 discussions

Files
by berend＠beard.nest.nl 01 Feb '02

01 Feb '02

* Moved (from: gpc) by Berend de Boer using timEd 1.10.b3+. Peter Gerwinski wrote in a message to Berend de Boer: PG> I tried to use Extended Pascal "binding" to assign a file PG> variable to an external -- existing -- file. I just copied PG> the "Assign" pro- cedure by Berend as published in PG> borland2ep.doc. It does not always work: I often get a PG> runtime error saying that the file did not exist. If you can repeat it, compile with another Extended Pascal compiler, for example Prospero's one. If that fails too, there is really something wrong with the code. But I suspect gpc. You're using which OS? Groetjes, Berend (-: fido: 2:281/527.23 email: berend(a)beard.nest.nl

4 3

Integrating a compiler into the GCC back end
by Tim Josling 04 Jan '00

04 Jan '00

Hi, I am working on a COBOL compiler. My plan is to integrate into the GCC back end. I am looking at how to do this. Currently I have about 19,000 lines of code, which is the preprocessor plus the cobol nucleus grammar parser (cobol is a big language), at timjosling.homepage.com. Currently I have the book 'Using and Porting GCC', plus a sample integration of a toy language, as well as the fortran and pascal implementations. Which I am poring through at the moment. Given that you guys have already done this, I was wondering if there is anyone there who may be able/willing to answer some questions for me if I get roadblocked? I am not asking to be spoon fed, but sometimes someone just knows the answer to a question that may take ages to work out by yourself. Any suggestions about starting points, documentation, who to speak to, pros and cons of using the gcc back end are more than welcome. Tim Josling

2 1

Re: Problem with rewrite on file of packed array of packed record
by Frank Heckenbach 30 Dec '99

30 Dec '99

David James wrote: > The attached program declares a direct access file whose elements are > PACKED ARRAYS of a PACKED RECORD. The program fails with error #405 > when a rewrite is issued for the file. Removing the PACKED from the > array declaration makes the error go away. Is this correct behaviour? It's a GPC bug. Thanks for the report. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Problem with rewrite on file of packed array of packed record
by david＠tcs01.demon.co.uk 30 Dec '99

30 Dec '99

The attached program declares a direct access file whose elements are PACKED ARRAYS of a PACKED RECORD. The program fails with error #405 when a rewrite is issued for the file. Removing the PACKED from the array declaration makes the error go away. Is this correct behaviour? program daj7(input,output); const maxcontrol = 170; maxcomp = 200; type TCHECK1=PACKED RECORD CHECH:0..47; (*6 bits*) CHECM:0..60; (*6 bits*) CHECS:0..60; (*6 bits*) CHECT:0..999; (*10 bits*) GENERATED:BOOLEAN; QUERY:BOOLEAN; from_audit:boolean; END; TCHECK=PACKED ARRAY [0..MAXCONTROL] OF TCHECK1; (*if declared as PACKED, get error 405 on the rewrite if not declared PACKED, runs OK*) var count:integer; f:file [0..maxcomp] of tcheck; begin rewrite(f,'daj7.fil'); (*./daj7: could not open `daj7.fil' (error #405) here *) for count:=0 to maxcomp do begin seekwrite(f,count); f^[0].chect:=count; put(f); end; close(f); reset(f,'daj7.fil'); for count:=1 to maxcomp do begin seekread(f,count); writeln(count:1,' ',f^[0].chect:1); end; close(f); end. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/> -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

1 0

Re: Bug? Variants don't overlay when they contain strings
by Frank Heckenbach 30 Dec '99

30 Dec '99

David James wrote: > Should the different variants in a variant record overlay in the same > memory? > > Previous Pascals I have used have guaranteed this, and I've got > low-level code that relies on this. > > [...] > > (I know the variants are not the same length, and they are intended > not to be.) As you assumed in your latter mail, this is intentional so the discriminants are not overwritten, and they can be properly initialized in the first place. Consider: record case Boolean of False: (s1 : String (42)); True: (s2 : String (99)); end; If the strings would overlay, in particular their disriminants would occupy the same place in memory. How should it be initialized? Either way, it would be wrong for at least one of the variants... So, after a discussion in comp.lang.pascal.ansi-iso where this topic came up concerning file variables (which also require some automatic initialization and finalization), we decided to do this in GPC for all types with automatic initialization and finalization (currently files and schemata, in the future this might also be Delphi compatible classes and user-defined initialized and finalized types), since the standard does not guarantee variants to overlay, anyway... There are two ways in GPC to get guaranteed overlaying (both non-standard, of course, since the standard does not assume anything about internal representations; both BP compatible), `absolute' declarations and variable type casts. E.g., in order to overlay a byte array to a variable v: var b: array [1 .. SizeOf (v)] of Byte absolute v; or type t = array [1 .. SizeOf (v)] of Byte; then `t (v)' can be used as a byte array overlayed to v. Russ Whitaker wrote: > You have more than an overlay problem. In standard pascal you expect ic[ 1 > ] to align > with the first character position of s and thus one character to the left > is the length of s. > Thus ic[0] is the length of s. This holds for UCSD/BP strings (which GPC does not yet implement, but that's planned). The only strings Standard Pascal knows are arrays of char without any length value. > Two different kinds of strings with the same name - string - does make a > bit of confusion. Perhaps the > oldstyle strings could be renamed "short string" ?? ( didn't think > changing the spelling to "stwing" > would fly ) When we implement the short strings, we'll have to do such a distinction. Our current planning goes like this: string (n): string schema (EP compatible) string [n]: short string (UCSD/BP compatible, where n must be <= 255) string: dependent on flags, by default undiscriminated schema, but in BP mode (or with a special switch) short string of capacity 255 (UCSD/BP compatible). Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Bug? Variants don't overlay when they contain strings
by Russ Whitaker 29 Dec '99

29 Dec '99

Hi David James wrote: > Subject: Bug? Variants don't overlay when they contain strings > Date: Tuesday, December 28, 1999 11:25 AM > > Should the different variants in a variant record overlay in the same > memory? > > Previous Pascals I have used have guaranteed this, and I've got > low-level code that relies on this. > > The simple example below shows that this is not true for GPC - the version > as reported by gpc -v is: > Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs > gpc version 19991030, based on 2.95.2 19991024 (release) > > The output from the program is: > > addr of i is: -1073742896 > addr of s is: -1073742760 > addr of ic is: -1073742668 > > program daj15(input,output); > type trec = record > case integer of > 1:(i:array [1..34] of integer); > 2:(s:string(80)); > 3:(ic:packed array[0..79] of char); > end; > > var r:trec; > > procedure sub(r:trec); > begin > writeln('addr of i is: ',integer(addr(r.i)):1); > writeln('addr of s is: ',integer(addr(r.s)):1); > writeln('addr of ic is: ',integer(addr(r.ic)):1); > end; as an aside, if you change the cast "integer" to "cardinal" the output will be a positive number > > begin > sub(r); > end. > > If the string s is removed from the record, then the same address is > reported for i and ic. > You have more than an overlay problem. In standard pascal you expect ic[ 1 ] to align with the first character position of s and thus one character to the left is the length of s. Thus ic[0] is the length of s. In extended pascal there is 8 bytes to the left of the first charactor position makingt ic[ 0 ] useless So you end up leaving s out of Trec but what you can do is index s like an array[ 1..CAPACITY] and use Setlength when you need to. Two different kinds of strings with the same name - string - does make a bit of confusion. Perhaps the oldstyle strings could be renamed "short string" ?? ( didn't think changing the spelling to "stwing" would fly ) Russ <russwhit(a)mind.net>

1 0

Re: Bug? Variants don't overlay when they contain strings
by david＠tcs01.demon.co.uk 29 Dec '99

29 Dec '99

In message <199912292231.OAA17912(a)ego.mind.net> "Russ Whitaker" writes: > Hi > David James wrote: > > Subject: Bug? Variants don't overlay when they contain strings > > > > Should the different variants in a variant record overlay in the same > > memory? > > > > You have more than an overlay problem. In standard pascal you expect ic[ 1 > ] to align > with the first character position of s and thus one character to the left > is the length of s. > Thus ic[0] is the length of s. > > In extended pascal there is 8 bytes to the left of the first charactor > position makingt ic[ 0 ] useless > So you end up leaving s out of Trec but what you can do is index s like an > array[ 1..CAPACITY] > and use Setlength when you need to. In this artificially simple example, yes; however my real-life example is much more complicated, some of the variants are themselves records which contain strings, the aim was to get a byte array which was overlaid on all the variants (which is then sent over a network connection to another machine where an identical variant record receives bytes into the byte array and then uses the appropriate variant). I can work around the problem (by throwing away the variant record, keeping the individual variants and copying them to the byte array as needed). My question is still: should variants overlay in memory? I think I understand why they don't (I assume it's so that the string capacities do not get smashed by the other variants), but it's a nasty feature that could do to be highlighted in the documentation (maybe it is, but I haven't found it). -- David James mailto:david@tcs01.demon.co.uk

1 0

using Crt unit
by Matija Papec 28 Dec '99

28 Dec '99

Hello all! I would like to hear someone who does not have problems using Crt unit on Linux. On Mandrake6.1 (distribution very similar to RedHat), gpc says the following: ---- gpc -c -g --automake /home/mpapec/pas/dumy.pas -o ./dumy.o /tmp/cc8xNyqX.s: Assembler messages: /tmp/cc8xNyqX.s:6193: Error: Symbol `Initexec' can not be both weak and common /tmp/cc8xNyqX.s:6193: Error: Symbol `Doneexec' can not be both weak and common gpc1: gpc exited with status 1 crt.pas:345: `/usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/crtc.c' could not be compiled ---- and these are problematical lines: --file:crtc.c-- /* Assign the Dos unit's variables to the following routines to be called before and after Exec. If Dos is not used, create dummies here. */ void (*Initexec)() __attribute__((weak)); void (*Doneexec)() __attribute__((weak)); ---- What should be putted here? TIA :)

2 1

UNSUBSCRIBE
by Claude Roy 28 Dec '99

28 Dec '99

croy(a)osiris.com Claude Roy President Osiris inc. croy(a)osiris.com http://www.osiris.com

1 0

UNSUBSCRIBE
by Ed Way 28 Dec '99

28 Dec '99

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