[fpc-pascal]ARM compiling error
I have tried to build last cvs version 1.9.4 for ARM and It can't
compile
I'm using ppc386 version 1.0.10 to make it!
#>
#> make clean all OS_TARGET=linux CPU_TARGET=arm
BINUTILSPREFIX=arm-linux-
#>
-- DUMP SCREEN ---
/usr/bin/ppc386 -dUNIX -Ur -Xs -OG2p3 -n -Fi../inc -Fi../i386 -Fi../unix
-Fii386 -FE. -di386 -dRELEASE ../unix/dos.pp
/usr/bin/ppc386 -dUNIX -Ur -Xs -OG2p3 -n -Fi../inc -Fi../i386 -Fi../unix
-Fii386 -FE. -di386 -dRELEASE ../unix/crt.pp
crth.inc(60,18) Fatal: Syntax error, ; expected but = found
make[4]: *** [crt.ppu] Error 1
make[4]: Leaving directory
`/trabajo/programas/freepascal/cvs/fpc/rtl/linux'
make[3]: *** [rtl] Error 2
make[3]: Leaving directory
`/trabajo/programas/freepascal/cvs/fpc/compiler'
make[2]: *** [cycle] Error 2
make[2]: Leaving directory
`/trabajo/programas/freepascal/cvs/fpc/compiler'
make[1]: *** [compiler_cycle] Error 2
make[1]: Leaving directory `/trabajo/programas/freepascal/cvs/fpc'
make: *** [build-stamp.linux] Error 2
--
--- this is line 60 in crth.inc-
TextAttr: Byte = $07; { Current text attribute }
--
it seems as know about Byte but not about initializating value in this
line, perhaps because it's byte type?
Any suggestion?
regards
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Schedule request (educational and olympiad applications of FPC)
[EMAIL PROTECTED] wrote: Furthermore, the International Olympiad in Informatics (IOI) this year is taking place in September, and software versions are in the process of being decided. Speaking of olympiads (and IOI), how about including e.g. DeCAL in the standard FPC distribution (e.g. in packages or something like that), because C++ programmers have STL and it could sometimes be an advantage to them. I mean very few people are able to implement e.g. a Red-Black tree during the competition. And for the ACM ICPC it's somewhat worse since there it's even more vital to code your programs quickly, so usually C++ with STL ends up being the language of choice. ...hope there aren't any licensing issues... ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]1st post
Hello,
Thanks for the quick answers.
Peter Vreman a écrit :
> > 2) " end [ {$IFNDEF REGCALL} 'eax','ecx', {$ENDIF} 'edi']; "
> > Is the previous line meaningful? (See the routine below)
>
> No, FPC 1.9.x follows standard calling conventions. The changed registers
> are fixed. This information is not used for assembler procedures. But for
> assembler blocks within a procedure the information is used.
With "standard calling conventions", do you mean I have to write
code like with Delphi (push/pop ebx,edi,esi)? Yesterday, I spent all
day long to remove all these push/pop :-)
Should I also write push/pop for eax,ecx,edx when REGCALL is not
defined?
> > 3) When P is a PUI32 (PUI32 = ^Longword), I use Inc(P,Count) to
> > increment P by Count (Count > 1). It compiles fine but there is the
> > message "Conversion between ordinals and pointers are not not
> > portable". What does it mean? Portable towards what? (I am compiling
> > with {$MODE OBJFPC})
>
> That is a bug, please submit it to the bug repository. The message means
> that you are loading a pointer to an ordinal (=integer). This can lead to
> problems when compiling for 64bit platforms like x86-64 (that is already
> working and going to be supported in 1.9.6).
I will do that.
> > 4) "Internal error 200310221". Let's say I have one program (set as
> > primary file) and one unit. The only way to compile (and to build)
> > both of them is to activate the unit window and to "build" from
> > there. In all other cases, "compile" and "build" stop with this
> > internal error. I suppose I didn't correctly configure something (?)
> > (Windows 98, AMD 2600+)
>
> That is a bug. Without sources we are not able to analyse and fix the
> problem. Try to minize the problem (guess that will be hard) and send me
> the sources so i can reproduce it.
Unfortunately, I am not able to reproduce it myself! Now that I use
a lot of units, it almost no more occurs. In fact, today it occurred
only once not when using the mouse but when hitting Ctrl-F9.
--
mm
http://www.ellipsa.net/
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal]Bug with "Level 2 Optimizations"
Hello, Here is a bug (?) of the compiler (FP 1.9.4) when setting Level 2 Optimizations. I post it here since I don't believe it is possible to use the bug report form. (I work with Win98, AMD 2600+) Types used in the code. type TBigInt = record Digits: PDigits;// pointer to a digit array (digits are longwords) Capacity: Longint; // memory size (in longwords) of Digits^ Size: Longint; // number of digits currently used in Digits^ Negative: Boolean; // TRUE if and only if negative (0 is non-negative) end; PBigInt = ^TBigInt; //-- // Set A^.Size equal to NewSize // ! The returned BigInt may be no more normalized. The calling proc has to // manage the normalization. //-- procedure BigIntSetSize(A: PBigInt; NewSize: Longint); begin Assert(Longword(NewSize) <= ucMAXSIZE32); // check both < 0 and > max with A^ do begin if NewSize > Capacity then BigIntSetCapacity(A,NewSize) else if NewSize < Size then begin nx_fill(@Digits^[NewSize],Size-NewSize,0); // fill with 0s if NewSize = 0 then Negative := false; end; Size := NewSize; end; end; compiled without optimization (the code works) # [325] begin NXINTEGERS_BIGINTSETSIZE$PBIGINT$LONGINT: # Temps allocated between ebp-16 and ebp-8 pushl %ebp movl%esp,%ebp subl$16,%esp movl%ebx,-16(%ebp) movl%esi,-12(%ebp) # Para A located at ebp-4 # Para NewSize located at ebp-8 movl%eax,-4(%ebp) movl%edx,-8(%ebp) # [328] with A^ do movl-4(%ebp),%ebx -> EBX := A movl%ebx,%eax # [330] if NewSize > Capacity then BigIntSetCapacity(A,NewSize) movl4(%eax),%eax cmpl-8(%ebp),%eax jl .L316 jmp .L317 .L316: movl-8(%ebp),%edx movl-4(%ebp),%eax callNXINTEGERS_BIGINTSETCAPACITY$PBIGINT$LONGINT jmp .L322 .L317: movl%ebx,%eax-> EAX := EBX = A # [332] if NewSize < Size then movl8(%eax),%eax -> EAX := A^.SIZE cmpl-8(%ebp),%eax compiled with Optimizations 2 # [325] begin NXINTEGERS_BIGINTSETSIZE$PBIGINT$LONGINT: # Temps allocated between ebp-16 and ebp-8 pushl %ebp movl%esp,%ebp subl$16,%esp movl%ebx,-16(%ebp) movl%esi,-12(%ebp) # Para A located at ebp-4 # Para NewSize located at ebp-8 movl%eax,-4(%ebp) movl%edx,-8(%ebp) # [330] if NewSize > Capacity then BigIntSetCapacity(A,NewSize) movl4(%eax),%ebx-> EBX IS SET WITH "A^.CAPACITY" cmpl%edx,%ebx jnl .L317 -> JUMP WITH EBX = A^.CAPACITY (INSTEAD OF A) movl%eax,%ebx -> EBX := A, SHOULD BE WRITTEN BEFORE 'jnl .L317' callNXINTEGERS_BIGINTSETCAPACITY$PBIGINT$LONGINT jmp .L322 .L317: # [332] if NewSize < Size then movl8(%ebx),%eax-> EBX <> A, ACCESS VIOLATION cmpl-8(%ebp),%eax I hope this is sufficient so that you can find the bug. I couldn't provide more source code, I just started to adapt my libraries to Free Pascal and, at the moment, almost nothing is debugged. -- mm http://www.ellipsa.net/ ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]1st post
> Hello,
>
> Thanks for the quick answers.
>
> Peter Vreman a écrit :
>> > 2) " end [ {$IFNDEF REGCALL} 'eax','ecx', {$ENDIF} 'edi']; "
>> > Is the previous line meaningful? (See the routine below)
>>
>> No, FPC 1.9.x follows standard calling conventions. The changed
>> registers
>> are fixed. This information is not used for assembler procedures. But
>> for
>> assembler blocks within a procedure the information is used.
>
> With "standard calling conventions", do you mean I have to write
> code like with Delphi (push/pop ebx,edi,esi)? Yesterday, I spent all
> day long to remove all these push/pop :-)
FPC is delphi compatible with it's calling conventions on i386.
> Should I also write push/pop for eax,ecx,edx when REGCALL is not
> defined?
See remark above. There is no difference with delphi anymore. Also note that
the REGCALL define is unsupported. It is only a temporary define used
internally for bootstrapping a 1.9.x compiler. It'll be removed without
notice in the development series after 2.0.
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
