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]
>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/
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 |
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]
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
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]
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]
> 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/
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/
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/
I would appreciate help from anyone and everyone, if possible!
I just downloaded the binary's to GPC for Win 95/NT.
I then downloaded the cygwin.dll from
ftp://ftp.cygnus.com/pub/gnu-win32/
I get a link error when I try to run any of the GPC programs. What have
I installed wrong?!
Any help will be appreciated!
-Olan Patrick Barnes
obarnes(a)online.emich.edu