Re: [fpc-pascal] Trash variables (-gt) - Translation
Le 18/01/2024 à 08:57, Michael Van Canneyt via fpc-pascal a écrit : On Thu, 18 Jan 2024, LacaK via fpc-pascal wrote: Hi *, I am translating "Trash variables" (from English to Slovak), but I can not find appropriate words. That's why I want to describe it in more words. Is this correct: "Initialize local variables with random values" ? Or better suggestion? That seems most correct to me. I think it is more something like 'specific pattern values' which are different depending on the number of 't' (extracted from current trunk): ./globals.pas:126: trashintvalues: array[0..nroftrashvalues-1] of int64 = ($,$,$EFEFEFEFEFEFEFEF,0); Thus -gt will use $ pattern, -gtt will use $ pattern, -gtttwill use $EFEFEFEFEFEFEFEF pattern, -g will use $ pattern for 'trashing' of local variables. Pierre ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] New VASM upgrade to 1.9d breaks z80-msxdos and z80-zxspectrum builds
Le 25/04/2023 à 10:40, Karoly Balogh a écrit :
Hi,
On Tue, 25 Apr 2023, Pierre Muller via fpc-pascal wrote:
I tested 1.9d version on a test machine,
m68k targets are OK, but z80 targets now fail with:
Executing "/FPC/compilers/cross-compiling/bin/z80-msxdos-vasmz80_std" with
command line "-quiet -Fvobj -o
/FPC/compilers/cross-compiling/pas/trunk/fpcsrc/rtl/units/z80-msxdos/si_prc.o
/FPC/compilers/cross-compiling/pas/trunk/fpcsrc/rtl/units/z80-msxdos/si
error 39 in line 95 of
"/FPC/compilers/cross-compiling/pas/trunk/fpcsrc/rtl/units/z80-msxdos/si_prc.s":
illegal relocation
> .word .Lc2,.Lc1-.Lc2
_prc.s"
si_prc.pp(67,4) Error: Error while assembling exitcode 1
si_prc.pp(67,4) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted
I'm not sure it was Nikolay's intention to support vasm for Z80, it was a
hack from be before the internal assembler existed... -.-'
Anyway, can you figure out when did it break? Did it work with 1.9c? Which
was the previous version you used?
I finally managed to take a look at this issue:
it seems to be related to some 'bug' inside our code:
rtl/zxspectrum/si_prc.pp contains this:
{ this *must* always remain the first procedure with code in this unit }
procedure _start; assembler; nostackframe; public name 'start';
label
bstart,bend,loop,loop2,our_int_handler,key_int;
asm
{ init the stack }
ld sp, offset fpc_stackarea_end
(Some z80 assembly code removed *)
{ When using the SDCC-SDLDZ80 linker, the first object module defines the
order of areas (sections). Since this module contains the startup code,
it is loaded first, so we define all the sections we use in the proper
order. }
area '_DATA'
area '_BSS'
bstart:
area '_BSSEND'
bend:
area '_HEAP'
area '_STACK'
area '_CODE'
end;
end.
The problem is that the assembly always generates some .debug_frame section,
even if -g- is used, and this section contains:
.word .Lc2,.Lc1-.Lc2
With .Lc2 being the start of _start code, and .Lc1 supposed to be at the end of
_start.
But the area pseudo-instructions do generate new .section instructions,
which lead vasmz80_std to rightfully consider that
.Lc1-.Lc2 is illegal because the two labels do not belong to the same section
anymore...
The problem is that I have no idea how to fix this issue...
Would it be possible to move the area pseudo-instructions elsewhere?
Pierre
PS:
Copying the .section entry of _start right before .Lc1 (like below) fixes the
assembly using vasmz80_std
.section .text.n_si_prc_$$__start,"acrx"
.Lc1:
Pierre
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] New VASM upgrade to 1.9d breaks z80-msxdos and z80-zxspectrum builds
I tested 1.9d version on a test machine, m68k targets are OK, but z80 targets now fail with: Executing "/FPC/compilers/cross-compiling/bin/z80-msxdos-vasmz80_std" with command line "-quiet -Fvobj -o /FPC/compilers/cross-compiling/pas/trunk/fpcsrc/rtl/units/z80-msxdos/si_prc.o /FPC/compilers/cross-compiling/pas/trunk/fpcsrc/rtl/units/z80-msxdos/si error 39 in line 95 of "/FPC/compilers/cross-compiling/pas/trunk/fpcsrc/rtl/units/z80-msxdos/si_prc.s": illegal relocation >.word .Lc2,.Lc1-.Lc2 _prc.s" si_prc.pp(67,4) Error: Error while assembling exitcode 1 si_prc.pp(67,4) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted Pierre Le 24/04/2023 à 15:27, Karoly Balogh via fpc-pascal a écrit : Hi, On Sat, 22 Apr 2023, Derek via fpc-pascal wrote: I downloaded the updated version of vasm v1.9d and compiled and installed as per Norman's document. Just as a final update to this thread, Frank informed me, that the official vasm 1.9d release is now out, so all users should upgrade to that instead of using the daily snapshot. Just in case. Charlie ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] VASM upgrade to 1.9 breaks cross compiler build
I tested it for m68k-sinclairql trunk target, and the rtl and packages completed successfully with this daily snapshot. Great! Pierre Le 21/04/2023 à 14:19, Karoly Balogh via fpc-pascal a écrit : Hi, On Wed, 19 Apr 2023, Norman Dunbar via fpc-pascal wrote: Thanks Charlie, I will be staying on 1.9 until further notice. I was in touch with Frank Wille, and he confirmed the issue was indeed in vasm, and he provided a fix. You can try to download the "Daily Snapshot", from the vasm site, and try it: http://sun.hasenbraten.de/vasm/index.php?view=source Note that this is just what it says on the tin - a daily source sanpshot, and he'll release 1.9d officially later. Can you confirm that this fixes your issue? Charlie ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] VASM upgrade to 1.9 breaks cross compiler build
I tried to update to the latest version 1.9c, and that one indeed does lead to this error: Executing "/home/muller/bin/m68k-sinclairql-vasmm68k_std" with command line "-quiet -elfregs -gas -Felf -m68000 -o /home/muller/pas/gitlab-fpc-source/rtl/units/m68k-sinclairql/system.o /home/muller/pas/gitlab-fpc-source/rtl/units/m68k-sinclairql/system.s" warning 1007 in line 4 of "/home/muller/pas/gitlab-fpc-source/rtl/units/m68k-sinclairql/system.s": scratch at end of line >.section .text.n_system_$$_mt_frjob$longint$longint,"awx" So the regression appeared between versions 1.9 and 1.9c. Checking of versions 1_9a and 1_9b confirms that the problem appeared in version 1_9a. Pierre Le 18/04/2023 à 16:43, Pierre Muller via fpc-pascal a écrit : Hi, I think that my daily tests are using vasm 1.9 for sinclairql, and I have no problems with them. could you please be a little more specific about the exact version of the compiler and the make command line you are using? I used current trunk compiler with: muller@gcc186:~/pas/trunk/fpcsrc$ make crossall CPU_TARGET=m68k OS_TARGET=sinclairql OPT="-n -vx" which uses version 1.9c muller@gcc186:~/pas/trunk/fpcsrc$ /home/muller/bin/m68k-sinclairql-vasmm68k_std vasm 1.9 (c) in 2002-2022 Volker Barthelmann And completes successfully: make[2]: Leaving directory '/home/muller/pas/gitlab-fpc-source' /usr/bin/echo Build > build-stamp.m68k-sinclairql /usr/bin/echo Build > base.build-stamp.m68k-sinclairql make[1]: Leaving directory '/home/muller/pas/gitlab-fpc-source' Pierre Le 18/04/2023 à 16:14, Norman Dunbar via fpc-pascal a écrit : Good Afternoon. After a long break, I decided to start work/play on the Sinclair QL FPC cross compiler. I noticed that using any release of the vasm assembler, from 1.9 onwards, breaks the "crossall" build. It spits out a number of "warning 1007: scratch at the end of line" errors, then the build fails with 2 errors -- neither of which are displayed. Reverting back to any of the 1.8 releases, 1.8l (ell) is the latest, and the build works fine. I'm pretty sure almost nobody is building the cross compiler for this particular bit of 1980s hardware, other than myself and a couple of others, but hopefully this message will be useful to someone. It could be that the later versions of the assembler are going to break other M68K systems? For best results, the 1.8l version of vasm can be obtained from http://phoenix.owl.de/tags/vasm1_8l.tar.gz and this is the most recent version of the assembler that will help build the cross compiler. Cheers, Norm. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] VASM upgrade to 1.9 breaks cross compiler build
Hi, I think that my daily tests are using vasm 1.9 for sinclairql, and I have no problems with them. could you please be a little more specific about the exact version of the compiler and the make command line you are using? I used current trunk compiler with: muller@gcc186:~/pas/trunk/fpcsrc$ make crossall CPU_TARGET=m68k OS_TARGET=sinclairql OPT="-n -vx" which uses version 1.9c muller@gcc186:~/pas/trunk/fpcsrc$ /home/muller/bin/m68k-sinclairql-vasmm68k_std vasm 1.9 (c) in 2002-2022 Volker Barthelmann And completes successfully: make[2]: Leaving directory '/home/muller/pas/gitlab-fpc-source' /usr/bin/echo Build > build-stamp.m68k-sinclairql /usr/bin/echo Build > base.build-stamp.m68k-sinclairql make[1]: Leaving directory '/home/muller/pas/gitlab-fpc-source' Pierre Le 18/04/2023 à 16:14, Norman Dunbar via fpc-pascal a écrit : Good Afternoon. After a long break, I decided to start work/play on the Sinclair QL FPC cross compiler. I noticed that using any release of the vasm assembler, from 1.9 onwards, breaks the "crossall" build. It spits out a number of "warning 1007: scratch at the end of line" errors, then the build fails with 2 errors -- neither of which are displayed. Reverting back to any of the 1.8 releases, 1.8l (ell) is the latest, and the build works fine. I'm pretty sure almost nobody is building the cross compiler for this particular bit of 1980s hardware, other than myself and a couple of others, but hopefully this message will be useful to someone. It could be that the later versions of the assembler are going to break other M68K systems? For best results, the 1.8l version of vasm can be obtained from http://phoenix.owl.de/tags/vasm1_8l.tar.gz and this is the most recent version of the assembler that will help build the cross compiler. Cheers, Norm. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Lack of PIC code support for m68k CPU (was: FPC crashes with Internal error 200502052 compiling shared library on m68k)
Hi, it is not only m68k CPU that is failing: mipsel, powerpc and ppc64 also show failures... For mipsel: (10028) Recompiling LCLProc, checksum changed for /usr/lib/mipsel-linux-gnu/fpc/3.2.2/units/mipsel-linux/rtl/math.ppu /usr/lib/lazarus/2.2.4/lcl/units/mipsel-linux/lclproc.ppu:lclproc.pas(67,64) Fatal: (10022) Can't find unit LCLProc used by ExtCtrls Fatal: (1018) Compilation aborted Error: /usr/bin/ppcmipsel returned an error exitcode So for that cpu, it seems to be a problem with Lazarus... For ppc64: (3104) Compiling un_xtrctdwrflnfo.pp /<>/src/un_xtrctdwrflnfo.pp(41,4) Fatal: (2022) User defined: powerpc architecture not supported Fatal: (1018) Compilation aborted Error: /usr/bin/ppcppc64 returned an error exitcode Seems to indicate the powerpc arch is not supported... (32bit-powerpc seems to fail earlier...) For m68k, (9009) Assembling gb2312freq /<>/components/chsdet/./src/CharDistribution.pas(181,7) Fatal: Internal error 200502052 Fatal: (1018) Compilation aborted Error: /usr/bin/ppc68k returned an error exitcode Error: (lazarus) Compile package chsdet 0.2.9: stopped with exit code 1 Error: (lazbuild) chsdet 0.2.9 compilation failed make[1]: *** [debian/rules:16: override_dh_install] Error 2 make[1]: Leaving directory '/<>' This is not a error linked to a shared library, as, according to: https://sources.debian.org/src/doublecmd/1.0.10-1/components/chsdet/src/CharDistribution.pas/ CharDistribution is a unit, not a library. For the second package, c-evo-dh, mipsel and m68k fail. For mipsel, this is related to the fact that -fpic is not the default mode, but it is required to be able to generate position independent code, which is usually required for shared libraries. For m68k, (3104) Compiling StdAI.lpr (3104) Compiling Protocol.pas Protocol.pas(1963,36) Fatal: Internal error 200502052 Fatal: (1018) Compilation aborted Error: /usr/bin/ppc68k returned an error exitcode make[1]: *** [debian/rules:27: override_dh_auto_build] Error 1 Here again, it is a unit that is compiled and generate the internal error: 200502052 After inspection inside the code source, it seems that indeed pic code is not supported by the Free Pascal compiler for m68k CPU... (not even in current trunk version). I don't know if anyone ever worked on this... Pierre Le 03/03/2023 à 13:42, Peter B via fpc-pascal a écrit : On Debian 12 (Bookworm) FPC release version 3.2.2 crashes on m68k when trying to build a shared library. See https://buildd.debian.org/status/package.php?p=doublecmd h Scroll down to "Tail of log for ... m68k:" I have searched the bug tracker and can't see any related issues. I don't use m68k, so I'm not affected myself with this, just F.Y.I. Should I raise it as an issue on GitLib? Cheers, Peter ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Enum property can't be published
Le 27/09/2022 à 11:22, Hairy Pixels via fpc-pascal a écrit :
On Sep 27, 2022, at 4:17 PM, Marco van de Voort via fpc-pascal
wrote:
3.2.2 compiles without warnings, 3.3.1 (i386-win32 from 17 sept:)
ptt.pp(14,44) Warning: This property will not be published
Possibly enums with assigned values (which can have gaps) are not safe to
publish, and this was only now noted?
I must have missed that.
What’s a good solution here? It looks like the code needs these enums to be 1
indexed, otherwise they are all in order with no gaps. If I could publish those
and just do a +1 first that would work.
Wouldn't adding NoError in front of the enum work for this case?
You don't need the explicit values, and their would not change!
TDiagnosticSeverity = ( NoError { will be 0},
Error {will stay equal to 1},
Warning {will stay equal to 2},
Information {will stay equal to 3},
Hint {will stay equal to 4}
);
Not a general solution, but a very simple one in that specific case!
Pierre
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] I am offering a $100 reward for linking static libraries
Le 22/08/2022 à 18:18, Henry Vermaak via fpc-pascal a écrit : On Sun, 21 Aug 2022 at 18:34, Anthony Walter via fpc-pascal wrote: I am also able to use mingw32 gcc to compile this same C source into a static library for Windows using these two commands while inside the folder containing the Chipmunk2D sources: x86_64-w64-mingw32-gcc-win32 -static -static-libgcc -std=gnu99 -ffast-math src/*.c -Iinclude -c -static and -static-libgcc are linking options, so they won't do anything here. You'll have to link libgcc in manually in your pascal source. You can always pass option to the external linker using '-k' option: Use -k-static (without space) or -k-lc or -k-L -k/DIR/ It can be good to use 'vx' option to see what is the command line really generated by the Free Pascal compiler when calling the external linker. Pierre ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross-compiler for ARM64 on Windows available?
Hello, this is normally a native aarch64-win64 compiler, not a cross-compiler package to be installed on linux. Note however that, as stated below, this was never tested. It will also not run on a Windows XP, unless you have an aarch64-windows_XP, but I am not aware of the existence of such machines. Regards, Pierre Le 21/06/2022 à 11:14, Wolfgang Hubert a écrit : Hi all, Pierre Muler via fpc-pascal wrote: You might also try this "completely untested" cross-installer: ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/aarch64-win64/fpc-3.3.1.aarch64-win64.built.on.x86_64-linux.tar.gz Thank you for pointing me to this installer. Since I am a Windows XP user and also blind, it would be too much effort for me to install a Linux machine or compile the compiler myself. I would rather wait until a compiler for the Windows host is available. If anyone has one, please let me know. Regards, Wolfgang ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross-compiler for ARM64 on Windows available?
Le 20/06/2022 à 23:53, Sven Barth via fpc-pascal a écrit : Am 20.06.2022 um 12:34 schrieb Wolfgang Hubert via fpc-pascal: Hi, I have developed a DLL for x64 Windows and compiled with fpc 3.2.2. I would like to compile the same code for ARM64 running Windows. I need this to support the MS Surface devices. Even though the platform list of the Lazarus Wiki https://wiki.freepascal.org/Platform_list lists "Windows for ARM64" under "Supported targets for AArch64" I did neither find a suitable cross-compiler for download, nor did I find any hints on how to compile for this platform in the documentation. Is there a release plan for an fpc version for ARM64 on Windows? When can I expect a suitable compiler to come? Windows on AArch64 is currently only supported in main thus you need to compile it yourself (see also https://lists.freepascal.org/pipermail/fpc-announce/2020-April/000614.html ). Also there are still some errors for which the origins haven't been found yet, so your mileage may vary... You might also try this "completely untested" cross-installer: ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/aarch64-win64/fpc-3.3.1.aarch64-win64.built.on.x86_64-linux.tar.gz See: ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/aarch64-win64/README-fpc-3.3.1.aarch64-win64.built.on.x86_64-linux Pierre ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Macro expanding error
Hi all,
Le 26/01/2022 à 02:59, Ryan Joseph via fpc-pascal a écrit :
I have this macro:
{$define TCallback := TCallback2}
which gives a long list of these errors.
warning: Expanding of macros exceeds a depth of 16.
What does this warning mean and how can I resolve it?
I just tested this:
muller@gcc140:~/pas/check$ ./test-macro-expansion
TCallBack2 called
muller@gcc140:~/pas/check$ cat ./test-macro-expansion.pp
procedure TCallBack2;
begin
writeln('TCallBack2 called');
end;
{$define TCallback := TCallback2}
begin
TCallBack();
end.
muller@gcc140:~/pas/check$ fpc -Sm test-macro-expansion.pp
Free Pascal Compiler version 3.2.2 [2021/05/16] for x86_64
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling test-macro-expansion.pp
Linking test-macro-expansion
12 lines compiled, 0.1 sec
muller@gcc140:~/pas/check$ ./test-macro-expansion
TCallBack2 called
So it is not as simple as Sven suggested...
Maybe there is another line like
{$define TCallback2 := TCallback}
Indeed:
muller@gcc140:~/pas/check$ cat ./test-double-macro-expansion.pp
procedure TCallBack2;
begin
writeln('TCallBack2 called');
end;
{$define TCallback := TCallback2}
{$define TCallback2 := TCallback}
begin
TCallBack();
end.
muller@gcc140:~/pas/check$ fpc -Sm ./test-double-macro-expansion.pp
Free Pascal Compiler version 3.2.2 [2021/05/16] for x86_64
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling ./test-double-macro-expansion.pp
test-double-macro-expansion.pp(9,10) Warning: Expanding of macros exceeds a
depth of 16.
test-double-macro-expansion.pp(9,10) Error: Identifier not found "TCallback"
test-double-macro-expansion.pp(14) Fatal: There were 1 errors compiling module,
stopping
Fatal: Compilation aborted
Error: /home/muller/pas/x86_64/fpc-3.2.2/bin/ppcx64 returned an error exitcode
You should probably try to look for another define somewhere else!
Pierre
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 3.2.2 (In)complete Boolean Evaluation on 32bit MacOS
Hi all, I took the liberty to report a bug issue about this problem, which I was able to reproduce on x86_64 3.2.2 release compiler. See https://bugs.freepascal.org/view.php?id=38973 for more details, Thanks for reporting, Pierre Muller Le 30/05/2021 à 15:47, Tobias Giesen via fpc-pascal a écrit : Hello, it seems that the newest 32-bit FPC sometimes creates complete Boolean Evaluation rather than partial, which causes my application to crash. My context is like this: type BOOL=LongBool; PBOOL=^LongBool; function DoSomething(const Cancel:PBOOL=nil); begin if Assigned(Cancel) and Cancel^ then Exit; end; This crashes because Cancel and Cancel^ are always evaluated, even if Cancel is nil. It works fine in 64-bit. Is this a known problem? Cheers, Tobias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] More problems in Sinclair QL port (M68K)
Hi Norman,
This all depend on the debugger capabilities,
if you can watch changes at a sepecific location,
the easiest is just to watch InOutRes memory position.
This will trigger a break in your program
exactly at the instruction which modifies the
InOutRes internal variable, which is
check troughout the RTL sources in lots of places.
In the hope that this helps,
Pierre Muller
Le 01/04/2021 à 16:33, Norman Dunbar via fpc-pascal a écrit :
Good afternoon all,
I've been working on the Sinclair QL version of the FPC runtimes and
I've got quite a lot of progress made. Unfortunately, I've hit a problem
with the Append() function. This is my stripped down test file showing
the problem:
{ Program to demonstrate the Append function. }
Var f : text;
begin
Assign (f,'ram1_test.txt');
Append(f);
{ Fwrite(f, 'This is the second line of text'); }
close (f);
end.
The Fwrite() call after Append() is commented out as it never gets that far.
The ram1_test.txt file already exists, and has a single line of text in
it. When I execute the compiled program I get a runtime error 103.
Looking at the RTL code, I see the following:
From sysfile.inc
At the end of do_open() we have the file already open in the correct
mode (Q_OPEN -- confirmed with debugger) and this gets executed:
{ append mode }
if ((Flags and $100)<>0) and
(FileRec(F).Handle<>UnusedHandle) then begin
do_seekend(filerec(f).handle);
filerec(f).mode:=fmOutput; {fool fmappend}
end;
end;
The call to do_seekend(), also in sysfile.inc, is this:
function do_seekend(handle: longint): longint;
begin
do_seek(handle, -1);
do_seekend := do_filepos(handle);
end;
And do_seek() is this:
procedure do_seek(handle, pos: longint);
var
res: longint;
begin
res := fs_posab(handle, pos);
if res < 0 then
Error2InOutRes(res);
end;
Finally, fs_posab() has been changed to the following, in qdos.inc:
function fs_posab(chan: Tchanid; new_pos: dword):longint; assembler;
nostackframe; public name '_fs_posab';
asm
{ D0 = chan, D1 = new_pos! }
move.l d3,-(sp)
move.l chan,a0
move.l new_pos,d1
moveq #_FS_POSAB,d0
moveq #-1,d3
trap #3
{ Test for EOF, else we get runtime errors }
cmpi.l #ERR_EF,d0
bne.s @noteof
@eof:
{ At EOF, we need to zero D0 to clear the error. }
moveq #0,d0
bra.s @done
@noteof:
tst.l d0
bne.s @quit
@done:
{ D1 is the new file position, unless EOF. }
move.l d1,d0
@quit:
move.l (sp)+,d3
end;
I changed it as I had problems with D0 being set to _FS_POSAB ($42)
before A0 was set to the channel id, which was passed in D0 due to the
"register" calling convention. Once I figured that out, I reorganised
the code to that shown above to be sure that we didn't get an "invalid
channel" error back from the OS as we were from A0 being $42 instead of
an actual channel ID.
Another problem is that when requesting a new position which is after
the end of the file, you get the "EOF error" code back ($FFF6 or
-10) from the OS. This wasn't checked for in the original code, so
caused an error exit. The code above resolves that problem.
Unfortunately, now when I exit from fs_posab() and there are no errors
in D0, I'm still getting a runtime error 103 from the Append(F) call.
When the code was attempting to write to the file after the Append()
call, the second line of text was not written to the file as it barfs in
Append().
The OS is returning the correct error code, $FFF6 or -10, for the
seek to the end of file, and the code exits from fs_posab() with D0
cleared of any errors when the request is for a file position bigger
than the file size. On a QL, Close() doesn't return any errors, so it's
definitely not there.
I've traced the fs_posab() calls through a debugger on my QL, and the
code does as it should, it exits back to Pascal with no errors in D0 as
it should.
Any pointers to where I should be looking are gratefully received, thanks.
Cheers,
Norm.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Looking for testers for 3.2.0 release cross-compilers for NDS, GBA and WII targets
Hi everyone, I was wondering if there are still users of Free Pascal compiler targeting arm-nds, arm-gba or powerpc-wii. I recently managed to re-generate 3.2.0 cross-install files for i386-win32 (usable of Windows OSes) target arm-gba, arm-nds and powerpc-wii. These zip files also include newly generated cross-binutils using unmodified binutils 2.35 release. There are also cross-install files for x86_64-linux systems, with binutils 2.34 (gba and wii) or 2.35 (nds). These files are not yet included in the download pages on the Free Pascal web-site, but there can be fetched from: ftp://ftp.freepascal.org/pub/fpc/dist/3.2.0/arm-nds/ ftp://ftp.freepascal.org/pub/fpc/dist/3.2.0/arm-gba/ and ftp://ftp.freepascal.org/pub/fpc/dist/3.2.0/powerpc-wii/ If someone who is still using Free Pascal for those targets could try the new files out and report about their usability, it would be great to get feedback! Pierre ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
