On Samstag, 12. Februar 2022 12:51:11 CET Florian Klämpfl via fpc-devel wrote:
> I think it must be tried, in practice one hits also some strange obstacle
> one never things before ... I would also expect that the former works and
> is the better solution though it requires also that the
Hi,
i've pushed now the remaining parts of the AES/VDI library (and also a few
other additions). Another few enhancements will be done soon, but the
ObjectGEM library can already be compiled.
I just wanted to share what problems may occur when porting PurePascal code to
FreePascal:
- the
On Montag, 7. Februar 2022 14:09:00 CET Sven Barth via fpc-devel wrote:
> A FPC compiled for 68020 can generate 68000 code just fine and the other way
> round (assuming of course that it was compiled without bugs ;) ). It's just
> that you need to provide it with the correctly compiled units. You
On Samstag, 29. Januar 2022 13:13:08 CET Karoly Balogh wrote:
> . I think this is the main issue, as
> I've seen GEMDOS has special calls for console I/O which are not being
> utilized now.
Yes, but when using standard handles 0 and 1, Fread() should work the same.
There should be no need to
On Samstag, 29. Januar 2022 13:41:24 CET Karoly Balogh via fpc-devel wrote:
> Additionally, for extending the OS interfaces, you probably also want to
> look into packages/tosunits.
Yes, thanks, i've seen that already. I has a few more functions than in rtl/
atari/, but still some functions
On Freitag, 28. Januar 2022 20:21:03 CET Karoly Balogh wrote:
> a fixed GAS/LD support would be nice, of
> course.
Yes, but currently i'm a bit lost here. Since that combination currently does
not support "smart linking", i guess i'll stick to vasm for now. There are
other parts that should be
On Samstag, 29. Januar 2022 14:55:30 CET Karoly Balogh wrote:
>Yes, but changing this is not trivial in platform independent code,
It doesn't have to, if it can be fixed in fpc_readln_end().
> Maybe Sven or someone can say more about the Windows analogy, I'm not
> familiar there.
Thats
Now that vasm is the default, how do i switch back to gas (i still want to try
to figure out what's wrong when using gas/ld)?
I tried -Agas, but then the compiler complains about an illegal parameter (so
at least the help message seems to be wrong).
Then i tried -Aas, but then the compiler
On Freitag, 28. Januar 2022 13:55:11 CET Thorsten Otto via fpc-devel wrote:
> i still want to try to figure out what's wrong when using gas/ld)
I get the the feeling that there must be something else going wrong:
- when i run the binary compiled by using vasm/vlink in mint, it works
- when i
On Samstag, 29. Januar 2022 16:03:32 CET Tomas Hajny via fpc-devel wrote:
> does it return individual characters, or does it
> return the whole line at once (the latter being the case for other FPC
> targets as far as I know)?
Just tried with a small test program, and the behaviour is a bit
On Freitag, 28. Januar 2022 13:55:11 CET Thorsten Otto via fpc-devel wrote:
> Then i tried -Aas, but then the compiler also complains:
>
>
>
> Warning: (treated as error) Assembler output selected "AS" is not compatible
> with "Atari ST/STE"
>
> Warn
On Dienstag, 1. Februar 2022 09:11:21 CET Pierre Muller via fpc-devel wrote:
> thus you should use
>-Aas-out
> compiler option.
Ah thx. Would make more sense to just use "as" like for other targets, but i
see that this target is also used for amiga.
On Freitag, 28. Januar 2022 18:04:12 CET Thorsten Otto via fpc-devel wrote:
> - Running the same binaries in SingleTOS, they both give me "Internal error
> 2004121202'. Then they both crash with a bus-error, too.
That internal error is currently striking back. This happens both
On Montag, 7. Februar 2022 14:34:12 CET Karoly Balogh wrote:
> but going with this would probably mean
> giving up TOS support.
Yes, that 8.3 restriction might be the worst that was ever made. But even
unices of that time allowed only 14 character long filenames.
I think you should not care
On Montag, 7. Februar 2022 14:09:00 CET Sven Barth via fpc-devel wrote:
> It's just that you need to provide it with the correctly compiled units
Yes, i see. But that requires some manual fiddling with the library
directories, and you need both 68000 and 68020 versions somehow.
How do the
Hi,
while working on some atari specific support in ExecuteProcess, i'm now
encountering some crash that seems to happen in fpc_dynarray_setlength:
FPC_DYNARR_SETLENGTH:
[6c94] 4e56 ffcc link a6,#-52
[6c98] 48ee 3cfc ffccmovem.ld2-d7/a2-a5,-52(a6)
On Donnerstag, 10. Februar 2022 14:21:54 CET Sven Barth via fpc-devel wrote:
> Anything else does not make sense.
>
> Cause in the variant you mentioned where would the allocated memory be
> stored?
I'm not that familiar with ObjectGEM yet, but i think the allocated pointer is
stored in some
On Donnerstag, 10. Februar 2022 19:13:15 CET Sven Barth via fpc-devel wrote:
> And how does one work with the created instance? How does one release it? Do
> you have an example for that?
Maybe some examples of ObjectGEM itself, like https://github.com/th-otto/
texel/tree/master/ogem/demo/zeit
On Montag, 7. Februar 2022 09:46:50 CET Karoly Balogh wrote:
> Does it also happen, when you compile everything for the 68020?
> (-Cp68020)
Nice, that's it. Compiling everything for 68020, and it works. Thats strange.
But that also explains why it worked a few days ago, because the default has
On Montag, 7. Februar 2022 10:31:01 CET Thorsten Otto via fpc-devel wrote:
> because the default has changed only recently.
That reminds me of another problem: if i'm not wrong, the compiler does not
use different sets of libraries depending on whether your are compiling for
68
On Montag, 7. Februar 2022 10:31:01 CET Thorsten Otto via fpc-devel wrote:
> Nice, that's it. Compiling everything for 68020, and it works.
Hm, or maybe not. A few hours later, installing a freshly compiled version, i
get that internal error again. Damn. Must be some other kind of randomn
On Montag, 7. Februar 2022 13:39:49 CET Karoly Balogh wrote:
> Is the compiler binary itself a 68020 or a 68000 binary?
All i changed was using
make zipinstall OS_TARGET=atari CPU_TARGET=m68k 'CROSSOPT=-Cp68020 '
so i think that should be a 68020
Hi
(I'm new to this list so please forgive me if i'm asking questions that have
already been answered elsewhere, and just point me to the right direction)
Inspired by some thread on the atari-forum (https://www.atari-forum.com/
viewtopic.php?f=16=41476=cd858e109f7cd4f1cae6c597ea35b66f )
i
On Dienstag, 25. Januar 2022 12:22:33 CET Karoly Balogh wrote:
> Hi,
>
> On Tue, 25 Jan 2022, Thorsten Otto via fpc-devel wrote:
> > Yes, a.out support (which is used on Atari) has been dropped in 2.31.
> > But i've added it back in, and cross-binutils of 2.34 can be fo
Hi Marcus,
thanks for your answers.
> yes the Atari version is compiled by Jenkins every commit
> https://build.alb42.de:8081/job/FPC_m68k-atari/ (to make sure the
> changes does not break the target) it uses the command line:
Yes, i saw the console output already. What i could not figure out
On Dienstag, 25. Januar 2022 11:27:11 CET Marcus Sackrow via fpc-devel wrote:
> hmm what do you mean? I wrote it, of course.
But is that a script that is stored somewhere, or is it just a setting inside
your Jenkins installation?
>newer ld support that but they can't be compiled for m68k
On Dienstag, 25. Januar 2022 11:07:35 CET Sven Barth via fpc-devel wrote:
> For the makefiles you need to set BINUTILSPREFIX=m68k-atari-mint- then
Thanks. I'm sure that i already tried that, and it did not work. But maybe i
did something wrong, trying it again (without the symlinks) seems to
On Dienstag, 25. Januar 2022 14:07:52 CET Sven Barth via fpc-devel wrote:
> Can it be that you forgot to write some reply here, Thorsten?
Hmpf, dunno what happened, so once again.
>If I'm not mistaken, GCC for
>Atari used to have some tool like this? Brownout, maybe?
Yes, but i never used that
On Dienstag, 25. Januar 2022 14:45:07 CET Thorsten Otto via fpc-devel wrote:
> And of course i have to find out what causes vlink to put that strange
> program flags in the header.
I think i found the reason for that. The offending lines in vlink/main.c are:
if (!strcmp
On Samstag, 16. April 2022 06:49:07 CEST J. Gareth Moreton via fpc-devel
wrote:
> but I haven't been able to find an authoritive
> source on this yet.
Did you check what for example GCC generates for similar C constructs? I don't
think it uses cmov at all.
On Dienstag, 17. Oktober 2023 09:32:16 CEST Marco van de Voort via fpc-devel
wrote:
> so the symbol "fnmatch" is NOT resolving to a match in "libc.so.6" where one
> would normally expect to find fnmatch defined
Usually, it is:
$ nm -D /lib64/libc.so.6 | grep fnmatch
000e493e T fnmatch
On Montag, 27. Juni 2022 04:43:46 CEST J. Gareth Moreton via fpc-devel wrote:
> testl$1,%ebx -> testb$1,%bl
Obviously, thats not the same. The latter will only compare the least-
significant byte against 1, and ignore the rest of the register. The former
will also compare the remainder
32 matches
Mail list logo
