Gpc

gpc@gnu.de

5400 discussions

Re: Inline Assembler Problems
by Peter Gerwinski 12 Jun '97

12 Jun '97

According to PredatorZeta: > > I receive the same invalid 386 instruction error message. > Mmmh...I investigate on this. I have found this (probably) bug in the > "as": > > movl $_TheArray(,%%esi,4), %%eax > > and > > movl %%eax, _TheArray(,%%esi,4) > > is accepted from the assembler without any problems. But sadly: > > movl %%eax, $_TheArray(,%%esi,4) > > is refused. If this isn't a bug, anyone know the reasons? I do not really know, but I guess that it's the following: The `$' denotes a constant value, something without a `$' denotes a memory reference. It is okay to move the constant `$_TheArray' (i.e. the ADDRESS of `_TheArray') into a register, whereas it is not possible to store the value of the %%eax register in the constant `$_TheArray'. But if it is so, I have problems to imagine what "movl $_TheArray(,%%esi,4), %%eax" means ... except if the `movl' is silently translated to a `leal'. Could please somebody check it out? 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: Whats wrong?!?
by Peter Gerwinski 12 Jun '97

12 Jun '97

According to Frank Heckenbach: > > Why is this correct? Isn't Text, being declared as an array of char, > treated as a 0-terminated string, meaning that the #0 should not be > printed? No. Text being declared as an array of char is treated as a string of fixed length. The Standard doesn't say anything about 0-termination. If GPC sometimes takes `chr ( 0 )' as the end of a string, this behaviour is a remainder of the C back-end and should be reported as a BUG. (I am not, however, speaking of `CString's (= `PChar's) which are a GNU (resp. Borland) extension.) 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: Inline Assembler Problems
by Bernhard Tschirren 12 Jun '97

12 Jun '97

>BTW I found a new real problem. With: > >movl %%eax, $_TheArray(,%%esi,4) > >I receive the same invalid 386 instruction error message. >Mmmh...I investigate on this. I have found this (probably) bug in the >"as": > >movl $_TheArray(,%%esi,4), %%eax > >and > >movl %%eax, _TheArray(,%%esi,4) > >is accepted from the assembler without any problems. But sadly: > >movl %%eax, $_TheArray(,%%esi,4) > >is refused. If this isn't a bug, anyone know the reasons? > YES, YES!! Thats what Ive been talking about all along! I must make my english a bit more clear - sorry. Cya L8r ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: Inline Assembler Problems
by PredatorZeta 12 Jun '97

12 Jun '97

Hello, Bernhard Tschirren <bernie(a)icenet.com.au> You wrote: > > > Var > > TheArray : Array[0..99] Of Integer; {32-bit} > > Begin > > Asm(" > > ... Code ... > > movl _Index, %esi (*you must double % if > you use Ext. Asm*) > > movl $_TheArray(,esi,4), %eax > > ... Code ... > > "); > > End. > > DOHHH! I am an idiot! In my code I had the two operands switched around! The > assembler was telling me that I was using an invalid 386 instruction. Is the > following really illegal? > > movl %eax,$_TheArray(,esi,4) First of all: ESI must be preceding by an "%" symbol __ALSO__ if it is between the brackets (have you get my doc?). Without this the assembler always will tell you that you was using an invalid 386 instruction. Are you sure that your variables are __static__, too? BTW I found a new real problem. With: movl %%eax, $_TheArray(,%%esi,4) I receive the same invalid 386 instruction error message. Mmmh...I investigate on this. I have found this (probably) bug in the "as": movl $_TheArray(,%%esi,4), %%eax and movl %%eax, _TheArray(,%%esi,4) is accepted from the assembler without any problems. But sadly: movl %%eax, $_TheArray(,%%esi,4) is refused. If this isn't a bug, anyone know the reasons? > I LOVE the inline assembler, except for the 15 local label limit. I know I > can prefix locals with an 'L' except when the compiler inlines the codeit > creates duplicate labels. Is there any way around that? In my doc i wrote that the labels can be from 0 to f only because I don't use more than 15 local labels at time. But of course, if you want, you can use for example "16:" or "19:" for indicate a local label, and this work fine. That's all folks!! Cya, PrZ. -- [<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<] | Codename: PrEdAtOr~Z; Sex: Male; Status: Free coder | * E-mail: predatorzeta(a)geocities.com * | URL: http://www.geocities.com/SiliconValley/Vista/6573 | [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]

1 0

Re: Whats wrong?!?
by Frank Heckenbach 12 Jun '97

12 Jun '97

Peter Gerwinski wrote: > > WriteLn('*',Text,'*'); { Prints out with padded #0 } > > I think we agree that this is correct. (On Linux, the #0s don't appear > on the screen ... I suspect the operating system (or the "terminal") "eats" > them.) Why is this correct? Isn't Text, being declared as an array of char, treated as a 0-terminated string, meaning that the #0 should not be printed? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: String Array Bug!
by Peter Gerwinski 11 Jun '97

11 Jun '97

According to Bernhard Tschirren: > > I found another bug (hidden feature)! Take a look at the code snippet below: > [...] > For some reason, there are SPACES after CPUName! I am using GPC 970420 for > DJGPP 2.01. This bug does not show up with Linux, but with DJGPP - and only if _p_directvideo (a Boolean variable in the GPC RTS) is FALSE. I will have a look at this ... Thanks for the report, 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: Whats wrong?!?
by Peter Gerwinski 11 Jun '97

11 Jun '97

According to Bernhard Tschirren: > > WriteLn('*',Text,'*'); { Prints out with padded #0 } I think we agree that this is correct. (On Linux, the #0s don't appear on the screen ... I suspect the operating system (or the "terminal") "eats" them.) > WriteLn('*',Trim(Text),'*'); { Also prints out with padded #0 } ISO 10206 says - in a way I have problems to think of a more cryptic one - that the thing which is stripped from the String is "the character space". This implies that there must be exactly one "space" - #32. Or did I overlook something? > WriteLn('*',Asciiz2Str(Text),'*'); { Segment Violation } This is not correct, but it's an unrecognized problem in the source: A String without specified length cannot be returned as the result of a function. BP assumes 255 in this situation which is quite natural because it's BP's maximum size for Strings, but GPC does *not* assume 4G in this case ... but zero. :-( In my current development version, GPC warns about the problem and assumes 255 (like BP), but I do not recommend to rely on this. Better always specify a length for Strings to be returned by functions: "Type String255 = String ( 255 ); Function Foo: String255;". (Or even better: avoid to return Strings as function results at all; use "Var Foo: String" instead which *is* valid.) > Bye (Im having trouble coming up with unique greetings :-) Me too, ;-) 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: Inline Assembler Problems
by Bernhard Tschirren 11 Jun '97

11 Jun '97

> Var > TheArray : Array[0..99] Of Integer; {32-bit} > Begin > Asm(" > ... Code ... > movl _Index, %esi (*you must double % if you use Ext. Asm*) > movl $_TheArray(,esi,4), %eax > ... Code ... > "); > End. DOHHH! I am an idiot! In my code I had the two operands switched around! The assembler was telling me that I was using an invalid 386 instruction. Is the following really illegal? movl %eax,$_TheArray(,esi,4) Now im doing it much nicer: Asm("... Code ... " "movl %0(,%1,4),%%eax " "... Code ... " : { No outputs } : "m" (TheArray), "r" (Index), : "eax"); I LOVE the inline assembler, except for the 15 local label limit. I know I can prefix locals with an 'L' except when the compiler inlines the code it creates duplicate labels. Is there any way around that? Thanks for your help ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Whats wrong?!?
by Bernhard Tschirren 11 Jun '97

11 Jun '97

The following does not work!?!? Is it a problem on my behalf or is it a GPC feature! :-) Function Asciiz2Str(Var InStr:{Packed} Array Of Char) : String; Var OutStr : String[255]; Index : Integer; Begin OutStr := ''; Index := 0; While (Index <= 255) And (InStr[Index] <> #0) Do Begin OutStr := OutStr + InStr[Index]; Inc(Index); End; Asciiz2Str := OutStr; End; Var Text : Packed Array[0..19] Of Char; Begin Text := 'Hello Word!'+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0; WriteLn('*',Text,'*'); { Prints out with padded #0 } WriteLn('*',Trim(Text),'*'); { Also prints out with padded #0 } WriteLn('*',Asciiz2Str(Text),'*'); { Segment Violation } End. Im using GPC 970420 for DJGPP 2.01. Im not very happy about the the Segmentation Violation. Also, it would be nice if the Trim cut out the trailing #0s, but this might break some programs... The first WriteLn is OK. Bye (Im having trouble coming up with unique greetings :-) ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

String Array Bug!
by Bernhard Tschirren 11 Jun '97

11 Jun '97

I found another bug (hidden feature)! Take a look at the code snippet below: PROGRAM: Type TStr10 = String[10]; Var CPUName : Array[0..5] Of TStr10 Value ('Unknown','80186','80286', '80386','80486','Pentium'); Var CPU : Integer; Begin For CPU := 0 To 5 Do WriteLn('*',CPUName[CPU],'*'); End. OUTPUT: *Unknown * *80186 * *80286 * *80386 * *80486 * *Pentium * For some reason, there are SPACES after CPUName! I am using GPC 970420 for DJGPP 2.01. Cya L8r ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

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