Menu
▾
▴
freemint-discuss — The official FreeMiNT Mailing List
You can subscribe to this list here.
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(30) |
Dec
(10) |
| 2018 |
Jan
(44) |
Feb
(44) |
Mar
(32) |
Apr
(49) |
May
(45) |
Jun
(7) |
Jul
(15) |
Aug
(84) |
Sep
(95) |
Oct
(36) |
Nov
(88) |
Dec
(41) |
| 2019 |
Jan
(21) |
Feb
(27) |
Mar
(67) |
Apr
(25) |
May
(69) |
Jun
(45) |
Jul
(65) |
Aug
(15) |
Sep
(20) |
Oct
(42) |
Nov
(109) |
Dec
(62) |
| 2020 |
Jan
(58) |
Feb
(36) |
Mar
(84) |
Apr
(169) |
May
(325) |
Jun
(267) |
Jul
(43) |
Aug
(3) |
Sep
(27) |
Oct
(25) |
Nov
(25) |
Dec
(7) |
| 2021 |
Jan
(11) |
Feb
(66) |
Mar
(1) |
Apr
(55) |
May
(24) |
Jun
(36) |
Jul
(10) |
Aug
|
Sep
(1) |
Oct
(21) |
Nov
(2) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(98) |
Mar
(15) |
Apr
(31) |
May
(4) |
Jun
(23) |
Jul
(45) |
Aug
(15) |
Sep
(75) |
Oct
(8) |
Nov
(10) |
Dec
(12) |
| 2023 |
Jan
(5) |
Feb
(49) |
Mar
(31) |
Apr
(3) |
May
(7) |
Jun
(5) |
Jul
(7) |
Aug
(161) |
Sep
(8) |
Oct
(7) |
Nov
(27) |
Dec
(26) |
| 2024 |
Jan
(24) |
Feb
(35) |
Mar
(11) |
Apr
(38) |
May
(13) |
Jun
(39) |
Jul
(2) |
Aug
(24) |
Sep
(7) |
Oct
(5) |
Nov
|
Dec
(18) |
| 2025 |
Jan
(82) |
Feb
(11) |
Mar
(9) |
Apr
(13) |
May
(2) |
Jun
(7) |
Jul
(2) |
Aug
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Thorsten O. <ad...@th...> - 2024-04-30 03:38:09
|
On Montag, 29. April 2024 23:35:37 CEST Miro Kropáček wrote: > Thorsten could this be related to your recent mintlib changes? Unlikely. Both <osbind.h> and <mint/osbind.h> are of course still in the archive. > #include <osbind.h> libcmini has its own copy of osbind.h, but only in the mint subdirectory. Dunno why this worked before. |
|
From: Thorsten O. <ad...@th...> - 2024-04-30 03:22:14
|
On Montag, 29. April 2024 18:08:33 CEST Miro Kropáček wrote: > Wouldn't be possible to move these folders somewhere else (build/deps or > whatever). Now it's really distracting. More distracting than before? And its not only the .deps directory that is created there, if you run "make check", the test executables are also build there. >either don't build any zic by default or build as many of them as many of libc.a's is there That would require to completely reorganize checkrules, since it currently only builds for a single architecture. Or maybe completely get rid of it, since it duplicates a lot of things from buildrules. But one thing after the other. >I don't know, it just seemed odd to have ELF this kind of preference. We could build them for a.out too of course, but they would be rather useless without a gdb that can handle a.out binaries. I just thought that it would be useful to have them build for elf where they actually can be used. But of course we can disable that again, to build other apps like qed they are not needed. |
|
From: Miro K. <mir...@gm...> - 2024-04-29 21:36:00
|
Hi, Thorsten could this be related to your recent mintlib changes? Run ./.scripts/install-libcmini.sh + cd .. + mkdir libcmini + wget -q -O - https://github.com/freemint/libcmini/archive/master.tar.gz + tar xzf - --strip-components=1 -C libcmini + cd libcmini + make CC build/./objs/putc.o CC build/./objs/isatty.o CC build/./objs/kbhit.o sources/kbhit.c:9:10: fatal error: osbind.h: No such file or directory #include <osbind.h> ^~~~~~~~~~ compilation terminated. make: *** [Makefile:162: build/./objs/kbhit.o] Error 1 -- http://mikro.atari.org |
|
From: Miro K. <mir...@gm...> - 2024-04-29 16:08:52
|
On Mon, 29 Apr 2024 at 17:55, Thorsten Otto <ad...@th...> wrote: > Yes, those are from the checkrules, when generating the .deps > subdirectories. But should be now better than before, which generated empty > .deps directories in the source directories. Moving them to the build > directory also avoids problems with parallel makes. > Wouldn't be possible to move these folders somewhere else (build/deps or whatever). Now it's really distracting. Not when you run it locally. Other cpu targets are build separately in > .scripts/build.sh for the snapshots only. For the tz directory (and also > for other directories where test executables are built), the rules from > checkrules are used, which currently only build for a single architecture. > But all libraries are built. I'd argue that if there is some special handling needed, either don't build any zic by default or build as many of them as many of libc.a's is there. Now it's really confusing for anyone not familiar with all the scripts, one would think there's only 68000 executable available, which, ironically, was exactly the case before your changes. Is there a reason not to build them? Apart from the additional compilation > time, there is no harm. Apparently nobody builded them for a long time, > otherwise such bugs as recently found would have popped up earlier. > I don't know, it just seemed odd to have ELF this kind of preference. -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-04-29 15:55:16
|
On Montag, 29. April 2024 17:09:39 CEST Miro Kropáček wrote: >quite a lot of them... Yes. Maybe i should have used the approach from other projects and redefine the register names in the header file instead, that would make a lot of the changes obsolete. But since i had to take a careful look at all register usages anyway... > you decided that "a0" should be replaced with "a1" to better fit the fast > call code later) changes to make it a bit smaller for the final fast call > patch. Yes. Similar changes were already done by @mfro for libcmini. With the recent changes to mintlib, and the PR in libcmini, those sources should be almost identical now again. >there are empty directories like "argp", "common" etc Yes, those are from the checkrules, when generating the .deps subdirectories. But should be now better than before, which generated empty .deps directories in the source directories. Moving them to the build directory also avoids problems with parallel makes. > zic (and others) doesn't seem to be built for other than 68000: Not when you run it locally. Other cpu targets are build separately in .scripts/build.sh for the snapshots only. For the tz directory (and also for other directories where test executables are built), the rules from checkrules are used, which currently only build for a single architecture. > 4. Is there a reason to build the debug targets on ELF by default? Is there a reason not to build them? Apart from the additional compilation time, there is no harm. Apparently nobody builded them for a long time, otherwise such bugs as recently found would have popped up earlier. > Perhaps it is not code at all That are string constants, which are put into the .text segment. The first one is "../../posix/wordexp.c", some expansion from an assert() i think. That also explains why they are different, because of different directory layout. |
|
From: Miro K. <mir...@gm...> - 2024-04-29 15:10:03
|
On Mon, 29 Apr 2024 at 10:37, Thorsten Otto <ad...@th...> wrote:
> Hm, why in subdirectories? I am just building 3 different archives for the
> binaries now (+ one with the libraries for all architectures)
>
Even better.
I've pushed the changes now. Hopefully did not mess anything up ;)
>
I have briefly went through the changes (quite a lot of them...):
1. I guess you could have separated those __HAVE_68881__ and whitespace /
syntax (ori #1 -> bset, movl -> move.l etc) / register (e.g. where you
decided that "a0" should be replaced with "a1" to better fit the fast call
code later) changes to make it a bit smaller for the final fast call patch.
2. "make WITH_DEBUG_LIB=yes WITH_PROFILE_LIB=yes' produces quite an odd
tree in "build/m68000": there are empty directories like "argp", "common"
etc from the source tree plus *.o and *.a files while in other "build"
directories there are just *.o and *.a files.
3. zic (and others) doesn't seem to be built for other than 68000:
(after all the targets are built...)
Making all in tz
make[1]: Entering directory
'/home/mikro/atari/projects/freemint/mintlib.git/tz'
m68k-atari-mint-gcc -m68000 -O2 -fomit-frame-pointer -fgnu89-inline
-D_GNU_SOURCE -D_REENTRANT -nostdinc
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include-fixed
-I../include -I. -I.. -I../time -c zic.c -o zic.o
m68k-atari-mint-gcc -m68000 -s -nostartfiles -nostdlib
../build/m68000/crt0.o zic.o -o zic -lgcc ../build/m68000/libc.a -lgcc
m68k-atari-mint-gcc -m68000 -O2 -fomit-frame-pointer -fgnu89-inline
-D_GNU_SOURCE -D_REENTRANT -nostdinc
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include-fixed
-I../include -I. -I.. -I../time -c zdump.c -o zdump.o
CFLAGS=-O2 -fomit-frame-pointer -fgnu89-inline
LDFLAGS=
m68k-atari-mint-gcc -m68000 -s -nostartfiles -nostdlib
../build/m68000/crt0.o zdump.o -o zdump -lgcc ../build/m68000/libc.a -lgcc
sed \
-e 's|AWK=[^}]*|AWK=awk|g' \
-e 's|TZDIR=[^}]*|TZDIR=/usr/share/zoneinfo|' \
-e 's|\(TZVERSION\)=.*|\1=2022g|' \
<tzselect.ksh >tzselect
chmod +x tzselect
m68k-atari-mint-gcc -m68000 -O2 -fomit-frame-pointer -fgnu89-inline
-D_GNU_SOURCE -D_REENTRANT -nostdinc
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include-fixed
-I../include -I. -I.. -I../time -c tzinit.c -o tzinit.o
m68k-atari-mint-gcc -m68000 -s -nostartfiles -nostdlib
../build/m68000/crt0.o tzinit.o -o tzinit -lgcc ../build/m68000/libc.a
-lgcc
make[1]: Leaving directory
'/home/mikro/atari/projects/freemint/mintlib.git/tz'
Making all in sunrpc
make[1]: Entering directory
'/home/mikro/atari/projects/freemint/mintlib.git/sunrpc'
m68k-atari-mint-gcc -m68000 -O2 -fomit-frame-pointer -fgnu89-inline
-D_GNU_SOURCE -D_REENTRANT -nostdinc
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include-fixed
-I../include -I. -I.. -I../time -c rpc_clntout.c -o rpc_clntout.o
m68k-atari-mint-gcc -m68000 -O2 -fomit-frame-pointer -fgnu89-inline
-D_GNU_SOURCE -D_REENTRANT -nostdinc
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include-fixed
-I../include -I. -I.. -I../time -c rpc_cout.c -o rpc_cout.o
m68k-atari-mint-gcc -m68000 -O2 -fomit-frame-pointer -fgnu89-inline
-D_GNU_SOURCE -D_REENTRANT -nostdinc
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include-fixed
-I../include -I. -I.. -I../time -c rpc_hout.c -o rpc_hout.o
m68k-atari-mint-gcc -m68000 -O2 -fomit-frame-pointer -fgnu89-inline
-D_GNU_SOURCE -D_REENTRANT -nostdinc
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include-fixed
-I../include -I. -I.. -I../time -c rpc_main.c -o rpc_main.o
m68k-atari-mint-gcc -m68000 -O2 -fomit-frame-pointer -fgnu89-inline
-D_GNU_SOURCE -D_REENTRANT -nostdinc
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include-fixed
-I../include -I. -I.. -I../time -c rpc_parse.c -o rpc_parse.o
m68k-atari-mint-gcc -m68000 -O2 -fomit-frame-pointer -fgnu89-inline
-D_GNU_SOURCE -D_REENTRANT -nostdinc
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include-fixed
-I../include -I. -I.. -I../time -c rpc_sample.c -o rpc_sample.o
m68k-atari-mint-gcc -m68000 -O2 -fomit-frame-pointer -fgnu89-inline
-D_GNU_SOURCE -D_REENTRANT -nostdinc
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include-fixed
-I../include -I. -I.. -I../time -c rpc_scan.c -o rpc_scan.o
m68k-atari-mint-gcc -m68000 -O2 -fomit-frame-pointer -fgnu89-inline
-D_GNU_SOURCE -D_REENTRANT -nostdinc
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include-fixed
-I../include -I. -I.. -I../time -c rpc_svcout.c -o rpc_svcout.o
m68k-atari-mint-gcc -m68000 -O2 -fomit-frame-pointer -fgnu89-inline
-D_GNU_SOURCE -D_REENTRANT -nostdinc
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include-fixed
-I../include -I. -I.. -I../time -c rpc_tblout.c -o rpc_tblout.o
m68k-atari-mint-gcc -m68000 -O2 -fomit-frame-pointer -fgnu89-inline
-D_GNU_SOURCE -D_REENTRANT -nostdinc
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include-fixed
-I../include -I. -I.. -I../time -c rpc_util.c -o rpc_util.o
m68k-atari-mint-gcc -m68000 -s -nostartfiles -nostdlib
../build/m68000/crt0.o rpc_clntout.o rpc_cout.o rpc_hout.o rpc_main.o
rpc_parse.o rpc_sample.o rpc_scan.o rpc_svcout.o rpc_tblout.o rpc_util.o -o
rpcgen -lgcc ../build/m68000/libc.a -lgcc
m68k-atari-mint-gcc -m68000 -O2 -fomit-frame-pointer -fgnu89-inline
-D_GNU_SOURCE -D_REENTRANT -nostdinc
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include
-I/home/mikro/gnu-tools/m68000/lib/gcc/m68k-atari-mint/7.5.0/include-fixed
-I../include -I. -I.. -I../time -c rpcinfo.c -o rpcinfo.o
m68k-atari-mint-gcc -m68000 -s -nostartfiles -nostdlib
../build/m68000/crt0.o rpcinfo.o -o rpcinfo -lgcc ../build/m68000/libc.a
-lgcc
make[1]: Leaving directory
'/home/mikro/atari/projects/freemint/mintlib.git/sunrpc'
and that's it, the build is finished. "zic", "zdump" etc are located in
"tz" (source) directory and not in "build".
4. Is there a reason to build the debug targets on ELF by default?
5. I compared libc.a from commit 0a659908 (ICE workaround) and head
The good news is that majority of the code is exactly the same, most of the
changes is a different address for given module. However one thing seemed
odd, in function _eval_expr_val:
old code:
39c: 0800 0001 btst #1,%d0
3a0: 66be bnes 360 <_eval_expr_val+0x144>
3a2: 60c2 bras 366 <_eval_expr_val+0x14a>
3a4: 1202 moveb %d2,%d1
3a6: 244d moveal %a5,%a2
3a8: 0c01 002b cmpib #43,%d1
3ac: 6600 fed8 bnew 286 <_eval_expr_val+0x6a>
3b0: 6000 ff24 braw 2d6 <_eval_expr_val+0xba>
000003b4 <.LC1>:
3b4: 2e2e 2f70 movel %fp@(12144),%d7
3b8: 6f73 bles 42d <_w_addmem+0x29>
3ba: 6978 bvss 434 <_w_addmem+0x30>
3bc:
000003c7 <.LC2>:
3c7: 6275 bhis 43e <_w_addmem+0x3a>
3c9: 6666 bnes 431 <_w_addmem+0x2d>
3cb: 6572 bcss 43f <_w_addmem+0x3b>
3cd: 203d .short 0x203d
3cf: 3d20 movew %a0@-,%fp@-
3d1: 2828 766f movel %a0@(30319),%d4
3d5: 6964 bvss 43b <_w_addmem+0x37>
new code:
39c: 0800 0001 btst #1,%d0
3a0: 66be bnes 360 <_eval_expr_val+0x144>
3a2: 60c2 bras 366 <_eval_expr_val+0x14a>
3a4: 1202 moveb %d2,%d1
3a6: 244d moveal %a5,%a2
3a8: 0c01 002b cmpib #43,%d1
3ac: 6600 fed8 bnew 286 <_eval_expr_val+0x6a>
3b0: 6000 ff24 braw 2d6 <_eval_expr_val+0xba>
000003b4 <.LC1>:
3b4: 2e2e 2f2e movel %fp@(12078),%d7
3b8: 2e2f 706f movel %sp@(28783),%d7
3bc: 7369 .short 0x7369
3be: 782f moveq #47,%d4
3c0: 776f .short 0x776f
3c2: 7264 moveq #100,%d1
3c4: 6578 bcss 43e <_w_addmem+0x38>
3c6: 702e moveq #46,%d0
3c8:
000003ca <.LC2>:
3ca: 6275 bhis 441 <_w_addmem+0x3b>
3cc: 6666 bnes 434 <_w_addmem+0x2e>
3ce: 6572 bcss 442 <_w_addmem+0x3c>
3d0: 203d .short 0x203d
3d2: 3d20 movew %a0@-,%fp@-
3d4: 2828 766f movel %a0@(30319),%d4
3d8: 6964 bvss 43e <_w_addmem+0x38>
what are those .short 0xXXXX statements in .LC1 ? That's -m68000, there
shouldn't be any unknown instruction involved. Perhaps it is not code at
all but I find it odd that it differs (again, both are -m68000, same
compiler, same flags).
--
http://mikro.atari.org
|
|
From: Thorsten O. <ad...@th...> - 2024-04-29 08:37:23
|
On Sonntag, 28. April 2024 10:03:39 CEST Miro Kropáček wrote: > with binaries in e.g. mintlib/<prefix>/bin/m68020-60 Hm, why in subdirectories? I am just building 3 different archives for the binaries now (+ one with the libraries for all architectures) >Nice, looking forward to it. I've pushed the changes now. Hopefully did not mess anything up ;) |
|
From: Miro K. <mir...@gm...> - 2024-04-28 08:04:03
|
On Sun, 28 Apr 2024 at 09:24, Thorsten Otto <ad...@th...> wrote: > Well atleast you should need them. Currently the invocation of tzinit in > mint.cnf is commented out. IMHO atleast tzinit & tzselect should be part of > the bootable builds (and also the zoneinfo database files of course) > Agreed. I'm currently reworking the build system for mintlib a bit, but for the > bootable builds the simplest solution is to provide prebuilt binaries > somewhere in the .scripts directory, like is done for coreutils and others. > Don't forget that bootable builds already download other snapshots (qed, hypview etc) so downloading a mintlib one, depack it + pick the suitable files for given CPU should be rather easy once the complete archives are there (with binaries in e.g. mintlib/<prefix>/bin/m68020-60). After the upcoming changes, you can just use "type=m68020" and > "type=coldfire" instead (cflags will be set automagically). But prebuilt > archives with the binaries will then also be available. > Nice, looking forward to it. -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-04-28 07:24:34
|
On Montag, 28. August 2023 00:00:40 CEST Thorsten Otto wrote: > You dont need them for building mintlib, but you would need them for the > bootable builds. That only applies to the few native tools there. Well atleast you should need them. Currently the invocation of tzinit in mint.cnf is commented out. IMHO atleast tzinit & tzselect should be part of the bootable builds (and also the zoneinfo database files of course) I'm currently reworking the build system for mintlib a bit, but for the bootable builds the simplest solution is to provide prebuilt binaries somewhere in the .scripts directory, like is done for coreutils and others. This can currently be achieved by: - cd to the tz directory - save binaries of the m68000 build somewhere - rm *.o - make cflags=-m68020-60 type=020 - save binaries somewhere - rm *.o - make cflags=-mcpu=5475 type=v4e - save binaries somewhere After the upcoming changes, you can just use "type=m68020" and "type=coldfire" instead (cflags will be set automagically). But prebuilt archives with the binaries will then also be available. |
|
From: OL <o....@lu...> - 2024-04-12 18:21:37
|
Le 10/04/2024 à 12:22, Jo Even Skarstein a écrit : > See https://www.atari-forum.com/viewtopic.php?p=461859#p461859 > > Memory protection on the V4 would be awesome, it would be a good alternative to my aging hardware. So who's up to the task? :) > > Jo Even > > Hello I will probably take some time for this, but it is not easy to have information on this topic. first need understand how it it work in Mint, then see if I can do something, this is probably my next goal on V4SA as hardware enhancement is out of my scope. Olivier |
|
From: Thorsten O. <ad...@th...> - 2024-04-11 17:08:37
|
Edit2: seems to be solved. It wasn't that fmul.d instruction (that should have caused a different exception, anyway), but a "fsin.x fp4" |
|
From: Thorsten O. <ad...@th...> - 2024-04-11 07:30:30
|
On Donnerstag, 11. April 2024 09:24:58 CEST Thorsten Otto wrote: > But it is just stated there: Edit: hm, i'm not entirely sure. If that really applies to '.X' (long double format) only, then Hatari incorrectly generates a Line-F exception for this instruction. But it seems to be handled by the FPSP060 package. |
|
From: Thorsten O. <ad...@th...> - 2024-04-11 07:25:22
|
On Donnerstag, 11. April 2024 09:09:51 CEST Miro Kropáček wrote: > There's nothing which would imply that fdmul.d #0x4022000000000000,%fp0 > should be emulated. But it is just stated there: F<op>.X #immediate,FPn is unimplemented, for all operations (including mul) |
|
From: Miro K. <mir...@gm...> - 2024-04-11 07:10:11
|
On Thu, 11 Apr 2024 at 08:39, Thorsten Otto <ad...@th...> wrote: > (immediate addressing has been removed for FPU instructions on 060). > What is the source of this information? According to the 68060 UM: [image: image.png] There's nothing which would imply that fdmul.d #0x4022000000000000,%fp0 should be emulated. -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-04-11 06:38:55
|
As recently found (see https://www.atari-forum.com/viewtopic.php? t=43666&start=50) gcc sometimes produces FPU opcodes which are not valid for 060 and have to be emulated: $ cat bla.c double x; void test(void) { x *= 9; } $ m68k-atari-mint-gcc -S -O2 -fomit-frame-pointer -m68060 -o - bla.c _test: fdmove.d _x,%fp0 fdmul.d #0x4022000000000000,%fp0 fmove.d %fp0,_x rts (immediate addressing has been removed for FPU instructions on 060). As you can see this also happens when compiling for 060 *only*. IMHO this is a bug, since it is not a valid opcode for that architecture. Do you think it is worth trying to fix this? |
|
From: Peter P. <pep...@gm...> - 2024-04-10 17:33:17
|
I’m not sure I get the point. The Atari 16/32-bit range isn’t open source. Nor is the Milan. Or the Hades. Or the 68k range of CPUs for that matter. How is the V4 in this case different? Perhaps it’s obvious, but I can’t see it. — PeP ons 10 apr. 2024 kl. 15:00 skrev Thorsten Otto <ad...@th...>: > On Mittwoch, 10. April 2024 13:18:25 CEST Jo Even Skarstein wrote: > > > someone from "our > > > side" that knows exactly what's needed from an MMU would have to follow > up > > > and keep the Apollo-team on the right track. > > To write free software for a closed-source system? > > Apart from that, i haven't seen any documentation on how the MMU on apollo > is designed. > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > |
|
From: Thorsten O. <ad...@th...> - 2024-04-10 12:59:54
|
On Mittwoch, 10. April 2024 13:18:25 CEST Jo Even Skarstein wrote: > someone from "our > side" that knows exactly what's needed from an MMU would have to follow up > and keep the Apollo-team on the right track. To write free software for a closed-source system? Apart from that, i haven't seen any documentation on how the MMU on apollo is designed. |
|
From: Jo E. S. <jo...@on...> - 2024-04-10 11:18:42
|
Yes, but it looks like Gunnar does not know much about TOS computers, so someone from "our side" that knows exactly what's needed from an MMU would have to follow up and keep the Apollo-team on the right track. Jo Even On Wed, 10 Apr 2024 13:06:45 +0200, "Miro Kropáček" <mir...@gm...> wrote: >> Just to clarify, he talks about what is needed from the hardware side. PeP >> already talked to Gunnar about this topic, so he is kind of aware but >> still: it's a hardware problem first, software (freemint support) second. >> >> On Wed, 10 Apr 2024 at 12:23, Jo Even Skarstein wrote: >> >> > See https://www.atari-forum.com/viewtopic.php?p=461859#p461859 >> > >> > Memory protection on the V4 would be awesome, it would be a good >> > alternative to my aging hardware. So who's up to the task? :) >> > >> > Jo Even >> > >> > >> > >> > >> > _______________________________________________ >> > Freemint-discuss mailing list >> > Fre...@li... >> > https://lists.sourceforge.net/lists/listinfo/freemint-discuss >> > >> >> >> -- >> http://mikro.atari.org >> _______________________________________________ >> Freemint-discuss mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: Miro K. <mir...@gm...> - 2024-04-10 11:07:04
|
Just to clarify, he talks about what is needed from the hardware side. PeP already talked to Gunnar about this topic, so he is kind of aware but still: it's a hardware problem first, software (freemint support) second. On Wed, 10 Apr 2024 at 12:23, Jo Even Skarstein <jo...@on...> wrote: > See https://www.atari-forum.com/viewtopic.php?p=461859#p461859 > > Memory protection on the V4 would be awesome, it would be a good > alternative to my aging hardware. So who's up to the task? :) > > Jo Even > > > > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > -- http://mikro.atari.org |
|
From: Jo E. S. <jo...@on...> - 2024-04-10 10:23:13
|
See https://www.atari-forum.com/viewtopic.php?p=461859#p461859 Memory protection on the V4 would be awesome, it would be a good alternative to my aging hardware. So who's up to the task? :) Jo Even |
|
From: Thorsten O. <ad...@th...> - 2024-04-05 10:40:04
|
On Dienstag, 12. März 2024 11:22:47 CEST Thorsten Otto wrote: > Maybe you want to look at my branch Another thing that i just found: https://github.com/bebbo/bgdbserver/tree/ master Dunno whether that talks the current protocol gdb expects, but at least it looks much simpler than hacking the binutil functions ;) |
|
From: Thorsten O. <ad...@th...> - 2024-04-04 14:41:18
|
On Donnerstag, 4. April 2024 16:11:19 CEST Vincent Rivière wrote: > I don't know what if there is a difference between "i" and "n" for > m68k: (define_constraint "i" "Matches a general integer constant." (define_constraint "n" "Matches a non-symbolic integer constant." So 'i' also allows symbolic constants like function addresses, but 'n' does not. Maybe that could make a small difference for bindings like Supexec. |
|
From: Vincent R. <vin...@fr...> - 2024-04-04 14:11:37
|
On 04/04/2024 at 10:13, Thorsten Otto wrote: > Maybe the constraints could be relaxed to "ri" so that immediate > constants can be pushed as such. But thas has to be carefully checked. Yes, EmuTOS BIOS bindings do something similar with "nr": https://github.com/emutos/emutos/blob/master/include/biosbind.h If the operand is a constant, it is used directly. If it is from memory, then GCC automatically puts it into a register first, to avoid the stack issue mentioned by Thorsten. This is really sad, GCC inline assembly syntax isn't suited for stack manipulation. BTW, I don't know what if there is a difference between "i" and "n" for m68k: https://gcc.gnu.org/onlinedocs/gcc/Simple-Constraints.html -- Vincent Rivière |
|
From: Thorsten O. <ad...@th...> - 2024-04-04 10:41:38
|
On Donnerstag, 4. April 2024 12:30:43 CEST Miro Kropáček wrote: > not to mention the function number for each trap The function number already has a constraint of "g" in the os calls, so that should not be a problem. |
|
From: Thorsten O. <ad...@th...> - 2024-04-04 10:39:59
|
Yes, but such changes really have to be tested carefully. I've already experimented with similar approaches, and in more complex situations it still produced wrong code (but IIRC, you luckily notice that already when compiling, either by getting an ICE or the assembler barfing on the instruction) |
5 messages has been excluded from this view by a project administrator.
