Gpc June 1997

gpc@gnu.de

25 participants
172 discussions

Re: `Word' data type
by Orlando Llanes 14 Jun '97

14 Jun '97

I know that a byte is 8 bits, but I glanced at soemthing womewhere that the Mac's smallest size that it can process is 16 bits <shrug> Maybe I'm wrong? > You mean: 16 bits? One "Byte"? At least this is against all > definitions I ever saw in textbooks. I have an idea, perhaps there could be platform dependant types, for example: VAR MyVar : PCByte; This way it would be treated as 8-bits on all platforms, the natural types can stay, all one has to do is use the platform type to compensate for it if necessary. This way, 1) the data works consistently across all platforms because (for example) they know that a PCByte is 8 bits, 2) If a byte is a different size on another platform, then it doesn't matter because the PCByte is the same no matter where it's compiled. I guess this could be accomplished by making the PCByte a natural Byte, but in the code, anything above the 8 bits is not used. > It would not be difficult to implement a compiler switch (*$16-bit *) (or > ... > GPC, it should not be 16 bits, but 64 bits! -- See ya! Orlando Llanes

1 0

Re: Type casting (was: `Word' data type)
by Orlando Llanes 14 Jun '97

14 Jun '97

Oh :} Sorry :} I briefly glanced at it, and what I saw was, for example: TYPE ShortInt = __byte__ Integer; Byte = __unsigned__ ShortInt; VAR AVar : Integer; ASmallVar : Byte; BEGIN ASmallVar := BytePtr(AVar)^; END. Something like that... What I meant was type casting using custom types, not with built-in or pre-defined types. If it already does this, sorry again :} > > I think that there should be a compiler directive to generate code, or > > maybe typecasting should be implemented, in case someone writes data from > > 32-bit word to prevent it from being read into a 16-bit word. I like > > Borland Style Type-Casting because it's logical, for example: [...]

1 0

Re: `Word' data type
by Berend de Boer 14 Jun '97

14 Jun '97

Peter Gerwinski wrote: > bits signed unsigned C equivalent > > 8 ByteInt Byte [unsigned|signed] char > 16 ShortInt ShortWord [unsigned] short > 32 Integer Word [unsigned] int == long > 64 LongInt LongWord [unsigned] long long I suggest keeping yourself more closely with Borland Pascal and Delphi. And implement range to byte mapping i.e. if I define a range as 0..255 it should occupy only one byte. I suggest: bits signed unsigned C equivalent 8 shortint byte [unsigned|signed] char 16 smallInt Word [unsigned] short XX Integer cardinal [unsigned] int == long 64 LongInt LongWord [unsigned] long long where XX is platform dependent: natural sizes, so could be 16, 32 or 64, 128 bits, etc. Groetjes, Berend.

1 0

Debugging GPC (was: Problems with OBJECTs)
by Peter Gerwinski 14 Jun '97

14 Jun '97

According to Bernhard Tschirren: > > The program below causes a Segment Violation (SIGSEGV) during compilation > using GPC-970510 for DJGPP 2.01. > > [...] > > Procedure TObj.DisposeIndex; > > {$M START} > Procedure DisposeEntry(Var Entry:PEntry); > {$M STOP} > Begin > If (Entry <> Nil) Then > [...] Thanks for the precise bug report. This makes it easier to debug GPC. I don't know how long it took you to find that place, but GPC has a debugging option `-dY' to dump the source to `stderr' during compilation. Using this, you immediately see the location where GPC crashed. The bug, however, seems to be somewhat harder ... working on it ... Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Enumerated types bug!
by Peter Gerwinski 14 Jun '97

14 Jun '97

According to Bernhard Tschirren: > > Enumerated types are not exported in the GPI file. For example: [...] Fixed. :-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: NOT A BUG Report :-)
by Peter Gerwinski 14 Jun '97

14 Jun '97

According to Bernhard Tschirren: > > Whew, this is not another bug report! :-0 Its a suggestion for a feature > that I'd like in GPC. :-) > Sometimes I have to link in 'C' (ugh) code with GPC. Usually this 'C' code > has been compiled into a ".a" library. Is there any way I can tell GPC to > automatically link this ".a" file with my program using automake? > [...] > Please tell me if Im setting my expectations of GPC a little too high :-) Too late: It's already implemented in my current development GPC. (-: (I see: It's really time for a new (beta) release (like promised), but before that I want to get rid of some really ugly bugs which only show up on a DEC Alpha. Since I don't have a DEC Alpha, it's not easy (and expensive)-; for me to hunt them.) To invoke this, wait till I eventually release the next beta; then say (*$L foo.o *) This has the same effect as an additional `foo.o' on the command line and should work with `foo.a' as well. In addition, (*$L foo.c *) has the same effect as (*$L foo.o *), except that - in combination with `--automake' - GPC tries to compile `foo.c' if `foo.o' does not exist or `foo.c' is younger than `foo.o'. Okay, so let me go on with GPC ... (* perhaps this weekend ... Daumen druecken! *) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: SERIOUS GPC BUG!!
by Peter Gerwinski 14 Jun '97

14 Jun '97

According to Bernhard Tschirren: > > Every time I compiled my programs with "-g" (debugging) the compiler crashed > with a SIGSEGV. With a bit of late-night detective-ing, I think I figured > WHY this happens! > > I managed to get an assembly dump of my program without the compiler > crashing. The "-g" option wrote ".def _(null) ... " to the assembly output. > Somehow, some NULL strings have crept into GPC.... :-( Whats even scarier is > that the number of _(null) defs varied between different compiles! That's a good hint for what kind of errors to look out; however it's hopeless to check all 2MB of GPC source code for NULL pointer dereferences ... ;-) and my own test programs are compiled with `-g -O3 -Wall' all the time. Could you please mail me a short test program which triggers the bug? Thanks in advance, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: `Word' data type
by Peter Gerwinski 14 Jun '97

14 Jun '97

According to Orlando Llanes: > > [...] On certain computers, > like the Macintosh I believe, a Byte is the size of a PC Word. You mean: 16 bits? One "Byte"? At least this is against all definitions I ever saw in textbooks. > I think that there should be a compiler directive to generate code, [...] It would not be difficult to implement a compiler switch (*$16-bit *) (or a command-line option `--16-bit') to make `Integer' and `Word' 16 bits etc., but I am not so sure that this is a good idea since GPC is a true 32-bit compiler. If we want to look out for a different "natural" data size for GPC, it should not be 16 bits, but 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/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Type casting (was: `Word' data type)
by Peter Gerwinski 14 Jun '97

14 Jun '97

According to Orlando Llanes: > > I think that there should be a compiler directive to generate code, or > maybe typecasting should be implemented, in case someone writes data from a > 32-bit word to prevent it from being read into a 16-bit word. I like > Borland Style Type-Casting because it's logical, for example: [...] Type casting *is* implemented. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

SERIOUS GPC BUG!!
by Bernhard Tschirren 13 Jun '97

13 Jun '97

If you look at the time stamp of this message you'll see that it was written at 2:30am. :-( I have just (hopefully) isolated a VERY SERIOUS GPC bug. Every time I compiled my programs with "-g" (debugging) the compiler crashed with a SIGSEGV. With a bit of late-night detective-ing, I think I figured WHY this happens! I managed to get an assembly dump of my program without the compiler crashing. The "-g" option wrote ".def _(null) ... " to the assembly output. Somehow, some NULL strings have crept into GPC.... :-( Whats even scarier is that the number of _(null) defs varied between different compiles! When "--automake" is enabled, the compiler crashes with a SIGSEGV. I dont think "AS" was ever invoked because it usually complains about those _(NULLS). I am using GPC-970510 for DJGPP 2.01. Now, I desperately need some sleep!! Good night :-) ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
18
Older →

Jump to page:

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