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: WongCK <won...@ya...> - 2024-06-13 08:08:05
|
Ah Ok... thanks for confirming my thoughts about the program.Having $SYSDIR as part of the pathname would be very use and helps a lot. I have to rename the path to xaloader manually and so it becomes 2nd nature to me when I update to a new snapshot. So it will be good to be able to use this sysdir.tos instead.
Another idea.... the wallpaper in XaAES. I only have a 1 copy of the wall paper but few Mint release. So I do a symlink of the XA_FORM.MFD to the one single wallpaper. This helps to keep disk usage lower. And it is a simple copy over the symlink to the new snapshot xaaes resolution folder ( of course the resolution needs to be the same for all snapshot which is HD on my CT63).
On Thursday, 13 June 2024 at 03:44:12 pm SGT, Miro Kropáček <mir...@gm...> wrote:
On Thu, 13 Jun 2024 at 08:37, WongCK via Freemint-discuss <fre...@li...> wrote:
Enlighten me how to use sysdir,tos.
It's just a convenience tool. If you have your mint.cnf / xaaes.cnf all set up, you don't need it.
It is targeted for users which like to boot a new complete ("bootable") snapshot and then decide to keep it: with help of sysdir.tos you can just copy mint.cnf & xaaes.cnf from your old snapshot. Of course, you have to upgrade from a snapshot which is already using sysdir.tos.
Ideally, one day sysdir.tos will go away and mint.cnf will allow parsing either relative paths or paths like $SYSDIR/xaaes/xaloader.prg.
--
http://mikro.atari.org_______________________________________________
Freemint-discuss mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freemint-discuss
|
|
From: Miro K. <mir...@gm...> - 2024-06-13 07:43:56
|
On Thu, 13 Jun 2024 at 08:37, WongCK via Freemint-discuss <
fre...@li...> wrote:
> Enlighten me how to use sysdir,tos.
>
It's just a convenience tool. If you have your mint.cnf / xaaes.cnf all set
up, you don't need it.
It is targeted for users which like to boot a new complete ("bootable")
snapshot and then decide to keep it: with help of sysdir.tos you can just
copy mint.cnf & xaaes.cnf from your old snapshot. Of course, you have to
upgrade from a snapshot which is already using sysdir.tos.
Ideally, one day sysdir.tos will go away and mint.cnf will allow parsing
either relative paths or paths like $SYSDIR/xaaes/xaloader.prg.
--
http://mikro.atari.org
|
|
From: WongCK <won...@ya...> - 2024-06-13 06:37:21
|
So it is time to update Mint on my system.I found a sysdir.tos inside Mint folder of v1-19-731 - what does sysdir.tos do?I remember some talks of have the sysdir environment available for use within the mint.cnf or something like that or I am just talking out of my head ?? I briefly looked into the Mint.cnf and Xaaes.cnf but missed finding it. Enlighten me how to use sysdir,tos. Thanks guys. |
|
From: Miro K. <mir...@gm...> - 2024-06-12 17:42:37
|
On Wed, 24 Jan 2024 at 16:50, Philippe Noble <phi...@gm...> wrote: > I am reviving this old thread as I continue to have an error message with > QED. > As I bumped into this yesterday on CT60TOS I told myself "Ok, this is the day this mystery gets solved". And it did: https://github.com/freemint/qed/issues/8. :) -- http://mikro.atari.org |
|
From: Miro K. <mir...@gm...> - 2024-06-11 22:32:11
|
On Tue, 11 Jun 2024 at 22:31, Dan Horák <da...@da...> wrote: > isn't it possible to reduce the amount of debuginfo put into the object > files? If "-g" is used to compile gcc, can you try with "-g1" (or even > with "-g0")? gcc is now a C++ application and it adds huge amounts of > debuginfo data. And in theory passing "-Wl,--no-keep-memory > -Wl,--reduce-memory-overheads" to the linker flags might also help. > Those are good hints however I wasn't able to convince gcc's CFLAGS/CXXFLAGS to listen to me. When I left them as is, it was compiled with "-O2 -g ...". However when I ran "CFLAGS='-O2 -fomit-frame-pointer' CXXLAGS='-O2 -fomit-frame-pointer' ./configure" it was not only not taken into account but all that was left was "-g" during the compilation (i.e. even the "-O2" somewhere disappeared). Perhaps I did something wrong but the room/patience for experiments quickly ran out... On Tue, 11 Jun 2024 at 23:17, Thorsten Otto <ad...@th...> wrote: > BTW, how long did it run before it failed? > About 20 hours, on aranym-mmu. -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-06-11 21:17:09
|
> just wanted to share something with you: even having 1900 MB of TT RAM in > Aranym didn't allow me to natively bootstrap gcc 13.3.0. Thats sad news, but it sounds strange. Building for mingw32 and cygwin32 was still possible, and those should have similar limits. BTW, how long did it run before it failed? |
|
From: Dan H. <da...@da...> - 2024-06-11 20:30:51
|
On Tue, 11 Jun 2024 20:53:11 +0200 Miro Kropáček <mir...@gm...> wrote: > Hi, > > just wanted to share something with you: even having 1900 MB of TT RAM in > Aranym didn't allow me to natively bootstrap gcc 13.3.0. FreeMiNT / mintlib > started to complain at the 2047 mark (mallocs failing very early on) and > IIRC 2 GiB is the limit of our TOS API anyway. > > The 1900 MB setup so-so passed the first (stage1) linking of 'cc1' but > finally failed on 'cc1plus' with being out of memory. So actually it seems > it was the linker's fault, not gcc's (for stage1 compilation I used my > native gcc 13.3.0 builds built by the cross compiler). > > So I guess that's it. There's no way to build gcc/g++ on Atari anymore. isn't it possible to reduce the amount of debuginfo put into the object files? If "-g" is used to compile gcc, can you try with "-g1" (or even with "-g0")? gcc is now a C++ application and it adds huge amounts of debuginfo data. And in theory passing "-Wl,--no-keep-memory -Wl,--reduce-memory-overheads" to the linker flags might also help. Fighting with OOM is not a uncommon issue in Linux distros on 32-bit platforms these days. Dan |
|
From: Christian H. <chr...@gm...> - 2024-06-11 20:03:39
|
That's really sad news :( Is it possible to build it on a Linux PC? Miro Kropáček <mir...@gm...> schrieb am Di., 11. Juni 2024, 20:54: > Hi, > > just wanted to share something with you: even having 1900 MB of TT RAM in > Aranym didn't allow me to natively bootstrap gcc 13.3.0. FreeMiNT / mintlib > started to complain at the 2047 mark (mallocs failing very early on) and > IIRC 2 GiB is the limit of our TOS API anyway. > > The 1900 MB setup so-so passed the first (stage1) linking of 'cc1' but > finally failed on 'cc1plus' with being out of memory. So actually it seems > it was the linker's fault, not gcc's (for stage1 compilation I used my > native gcc 13.3.0 builds built by the cross compiler). > > So I guess that's it. There's no way to build gcc/g++ on Atari anymore. > > -- > http://mikro.atari.org > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > |
|
From: Miro K. <mir...@gm...> - 2024-06-11 18:53:35
|
Hi, just wanted to share something with you: even having 1900 MB of TT RAM in Aranym didn't allow me to natively bootstrap gcc 13.3.0. FreeMiNT / mintlib started to complain at the 2047 mark (mallocs failing very early on) and IIRC 2 GiB is the limit of our TOS API anyway. The 1900 MB setup so-so passed the first (stage1) linking of 'cc1' but finally failed on 'cc1plus' with being out of memory. So actually it seems it was the linker's fault, not gcc's (for stage1 compilation I used my native gcc 13.3.0 builds built by the cross compiler). So I guess that's it. There's no way to build gcc/g++ on Atari anymore. -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-06-09 16:35:09
|
On Sonntag, 9. Juni 2024 17:45:07 CEST WongCK via Freemint-discuss wrote: > I have been following the updates from polarssl to mbedtls. As you mentioned > in AF, the migration is pretty simple by just changing the prefix to > mbedtls. Yes, but mbedTLS has one big disadvantage compared to openssl/wolftls: they have completely removed support for TLSv1.1. In other libs it is also disabled by default, but it is still there and can be enabled if you compile the library yourself. So if you need that support because you are talking to old servers, newer versions of mbedtls might not work. OTOH, it is much smaller. >gcc-14 with enable-checking took 4 mins 15 secs >gcc-14 without enable-checking took 2 mins 52 secs Thats still quite a difference, would not have expected that. So recompiling them again was atleast not for nothing ;) |
|
From: WongCK <won...@ya...> - 2024-06-09 15:46:03
|
Thanks the Atari mbedtls link.
I already compiled it with gcc-14 and using it with my programs, except the programs are not upload to my website yet.The programs that uses TLS 1.3 on my website are still v3.40.
Unlike Rajah, I have been following the updates from polarssl to mbedtls. As you mentioned in AF, the migration is pretty simple by just changing the prefix to mbedtls. They even have a doc that tells you what to do.
Back to gcc topic....
Just for kicks, I measure compiling a small library that I use, using both gcc-14 with/without enable-checking:gcc-14 with enable-checking took 4 mins 15 secs
gcc-14 without enable-checking took 2 mins 52 secs So not double time.
I just used rather clumsy method to measure -- just put "date" into the Makefile before and after the compile, so nothing seriously scientific about it.
On Sunday, 9 June 2024 at 08:46:18 pm SGT, Thorsten Otto <ad...@th...> wrote:
> it's the latest v3.6.0.
That is now also available at
http://tho-otto.de/crossmint.php#mbedtls
(but was compiled by gcc-7)
_______________________________________________
Freemint-discuss mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freemint-discuss
|
|
From: Thorsten O. <ad...@th...> - 2024-06-09 12:46:02
|
> it's the latest v3.6.0. That is now also available at http://tho-otto.de/crossmint.php#mbedtls (but was compiled by gcc-7) |
|
From: WongCK <won...@ya...> - 2024-06-09 11:58:12
|
Thanks. I will try them.it's the latest v3.6.0. On Friday, 7 June 2024 at 09:21:53 pm SGT, Thorsten Otto <ad...@th...> wrote: I've recompiled them now without those checks (both gcc-13 and gcc-14). Time for another try ;) BTW, the code you sent me to trigger the bug was from mbedtls. Which version are you trying to compile? _______________________________________________ Freemint-discuss mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: Thorsten O. <ad...@th...> - 2024-06-07 13:21:30
|
I've recompiled them now without those checks (both gcc-13 and gcc-14). Time for another try ;) BTW, the code you sent me to trigger the bug was from mbedtls. Which version are you trying to compile? |
|
From: WongCK <won...@ya...> - 2024-06-07 12:05:37
|
I felt it was like double the time to compile the same code as compared to before.Did not measure it but so may be in the region of 50% may be more realistic.
On Friday, 7 June 2024 at 01:45:24 am SGT, Miro Kropáček <mir...@gm...> wrote:
On Thu, 6 Jun 2024 at 17:23, Thorsten Otto <ad...@th...> wrote:
As far as i've seen, that mostly enable some assertion checks. That should normally be hardly noticable, given that the compiler is surely already not very fast on real hardware.
>From my experience on working on ScummVM, asserts did make a big difference. People normally (i.e. on PC) don't notice them (except some extreme cases) but on Atari, all it takes is one assert in an often-called inner loop and performance goes 50% down.
I have no problem removing that again, with the risc that if the compiler generates bad code, this will be harder to notice. In the worst case, it will cause you to hunt bugs in your code that are really just the compilers fault ;)
If you take into account that such a bug occurs maybe once per year, I think it's ok. We can always provide an additional build with the check(s) enabled when such situations occur.
--
http://mikro.atari.org_______________________________________________
Freemint-discuss mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freemint-discuss
|
|
From: Miro K. <mir...@gm...> - 2024-06-06 17:45:12
|
On Thu, 6 Jun 2024 at 17:23, Thorsten Otto <ad...@th...> wrote: > As far as i've seen, that mostly enable some assertion checks. That should > normally be hardly noticable, given that the compiler is surely already not > very fast on real hardware. > >From my experience on working on ScummVM, asserts did make a big difference. People normally (i.e. on PC) don't notice them (except some extreme cases) but on Atari, all it takes is one assert in an often-called inner loop and performance goes 50% down. I have no problem removing that again, with the risc that if the compiler > generates bad code, this will be harder to notice. In the worst case, it > will cause you to hunt bugs in your code that are really just the compilers > fault ;) > If you take into account that such a bug occurs maybe once per year, I think it's ok. We can always provide an additional build with the check(s) enabled when such situations occur. -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-06-06 15:22:54
|
On Donnerstag, 6. Juni 2024 16:19:47 CEST WongCK via Freemint-discuss wrote: > --enable-checking is not slightly slower... I feel it is a lot slower. Any > chance of removing it? As far as i've seen, that mostly enable some assertion checks. That should normally be hardly noticable, given that the compiler is surely already not very fast on real hardware. I have no problem removing that again, with the risc that if the compiler generates bad code, this will be harder to notice. In the worst case, it will cause you to hunt bugs in your code that are really just the compilers fault ;) |
|
From: WongCK <won...@ya...> - 2024-06-06 14:20:01
|
On Sunday, 2 June 2024 at 08:21:19 pm SGT, Thorsten Otto <ad...@th...> wrote:
--enable-checking is not slightly slower... I feel it is a lot slower. Any chance of removing it?Guess it gives me the chance to get a longer break during compilation.
- conclusion 1: we should think about adding --enable-checking=misc to our build scripts. That adds some assert checking, making the compiler slightly slower, but would catch such overflows which may or may not cause a bus-error.
_______________________________________________
Freemint-discuss mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freemint-discuss
|
|
From: Thorsten O. <ad...@th...> - 2024-06-03 13:38:35
|
On Montag, 3. Juni 2024 14:48:00 CEST Miro Kropáček wrote: > there's not so many syscalls and even the majority of them are very close to > Linux. Might be possible. The syscall parser in mintlib even generates everything you need to implement a linux-like syscall() function. |
|
From: Miro K. <mir...@gm...> - 2024-06-03 12:48:18
|
On Mon, 3 Jun 2024 at 14:40, Thorsten Otto <ad...@th...> wrote: > Maybe you can have a look at it again? > Yeah, on my list. I put a lot of time into that so I don't want to abandon it. But Eero is right, qemu is not an option in our case. We need something > that is able to run atari executables. > Another fun project would be a wine-like emulator: running mint executables on Linux-m68k in qemu. ;) If you think about it, it's not so hard: we have only static libraries, there's not so many syscalls and even the majority of them are very close to Linux. -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-06-03 12:40:18
|
On Montag, 3. Juni 2024 14:16:45 CEST Miro Kropáček wrote: > Did you report it upstream as well? So they know that their optimisation is > not so great after all. Yes, there was already an open bug report, so i added my findings there: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 But if you look at the git log of the master tree, you will see that there have already been some fixes after the original patch, none of them fixed the current problem, and other targets than m68k were also affected. >It was working pretty well but then Travis closed its doors and that was the end of it. Maybe you can have a look at it again? Should not be too hard to convert the travis scripts to github actions. And all the native tools should be available, either old versions from sparemint, or newly compiled ones from my site. I think some of them aren't even needed, eg. perl & m4 are imho only needed to regenerate the configure scripts using autoconf, but that should not happen. But Eero is right, qemu is not an option in our case. We need something that is able to run atari executables. |
|
From: Miro K. <mir...@gm...> - 2024-06-03 12:17:08
|
On Sun, 2 Jun 2024 at 14:21, Thorsten Otto <ad...@th...> wrote: > Phew, i think i found it. Seems the bug was introduced by > > > https://github.com/th-otto/m68k-atari-mint-gcc/commit/04c9cf5c786b94fbe3f6f21f06cae73a7575ff7a > > Good work, must have been a real PITA to find! > Luckily, that optimization can be turned off by -ffold-mem-offsets. This > is only in gcc-14.1.0, not in gcc-13.3.0 (but may eventually appear in the > next release). > Did you report it upstream as well? So they know that their optimisation is not so great after all. - conclusion 1: we should think about adding --enable-checking=misc to our > build scripts. That adds some assert checking, making the compiler slightly > slower, but would catch such overflows which may or may not cause a > bus-error. > Hmm, not a bad idea. Cross-compiling is fast anyway. - conclusion 2: we need to find some way to test the compiler. Compiling it > by itself would be a first step, but was not enough in this case (the > cross-compiler could compile itself, but generates wrong code that caused > only trouble when running the m68k executable). Obviously there is no easy > way to test the native compiler, maybe qemu or aranym can help here. > A few years ago (time flies...) I had a completely ssh-driver aranym setup on Travis: https://github.com/m68k-atari-mint/bootstrap. The idea was to set up a basic development image to natively (!) compile packages. It was working pretty well but then Travis closed its doors and that was the end of it. Now with GitHub Actions we could do the same -- starting with bootstrapping the gcc itself. -- http://mikro.atari.org |
|
From: Eero T. <oa...@he...> - 2024-06-03 11:49:45
|
Hi, On 3.6.2024 14.08, Thorsten Otto wrote: > On Montag, 3. Juni 2024 11:50:57 CEST Eero Tamminen wrote: >> tried "gcc hello.c" and it failed due to missing execve(). > > Actually mintlib tries its best to simulate the vfork()/execve thing even for > TOS, but i think its not good enough for gcc's purpose. Amongst others, it > also uses pipes for redirection. Most of the code for this is in libiberty > (https://github.com/th-otto/m68k-atari-mint-gcc/blob/mint/gcc-13/libiberty/ > pex-unix.c) The actual error is: GEMDOS 0x4B Pexec(200, 0x3ef8a6, 0x3ef827, 0x3f051e) at PC 0x137C02 : error trying to exec '/usr/lib/gcc/m68k-atari-mintelf/14/collect2': execv: Function not implemented > Another problem may be the symlinks for as, ld etc. in /usr/m68k-atari- > mintelf/bin Why they would be a problem? With GEMDOS HD, all files appear as normal ones, and those names are unique within 8+3 chars. As to content under /usr/lib/gcc/m68k-atari-mintelf/14/, "libstdc++.a" and "libstdc++exp.a" map to same 8+3 name, but if one knows whether code is built with exceptions, one can remove the non-relevant. Compiling anything than minimal C++ code is unlikely to work though because there seem to be a lot of C++ headers which are not unique with first 8+3 chars. - Eero |
|
From: Thorsten O. <ad...@th...> - 2024-06-03 11:08:26
|
On Montag, 3. Juni 2024 11:50:57 CEST Eero Tamminen wrote: > tried "gcc hello.c" and it failed due to missing execve(). Actually mintlib tries its best to simulate the vfork()/execve thing even for TOS, but i think its not good enough for gcc's purpose. Amongst others, it also uses pipes for redirection. Most of the code for this is in libiberty (https://github.com/th-otto/m68k-atari-mint-gcc/blob/mint/gcc-13/libiberty/ pex-unix.c) Another problem may be the symlinks for as, ld etc. in /usr/m68k-atari- mintelf/bin |
|
From: Eero T. <oa...@he...> - 2024-06-03 09:51:11
|
Hi,
On 3.6.2024 11.39, Thorsten Otto wrote:
> On Montag, 3. Juni 2024 10:24:59 CEST Eero Tamminen wrote:
>> I would suggest using Hatari for debugging these.
>
> Maybe next time ;) The problem has been identified and solved.
>
> But in general it is difficult to use Hatari in such scenarios. First off the
> gcc toolchain requires MiNT,
I see, it seems to do MiNT OS calls [1].
> and then Hatari is much slower than aranym, even
> when comparing the non-jit version of aranym to Hatari using fast-forward.
Yes, if GEMDOS HD cannot be used, things are much awkward.
Is OLDTOSFS still a thing?
- Eero
[1] I downloaded the v14 MINTELF GCC, added some symlinks:
for i in m68k-atari-mintelf-*; do
name=${i#m68k-atari-mintelf-}; \
name=${name%-14*}; \
ln -s $i $name.ttp; \
done
and tried "gcc hello.c" and it failed due to missing execve().
|
5 messages has been excluded from this view by a project administrator.
