freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] "r" modifiers in osbind.h & falcon.h

[Miro K. <mir...@gm...>]

On Thu, 4 Apr 2024 at 12:25, Thorsten Otto <ad...@th...> wrote:

> No, that does not matter:
>
Hmm. This is indeed an intriguing demonstration, compilers really are smart
these days. This alone could save quite a lot of register shuffling as you
usually call OS functions with some constants, sometimes all of them (not
to mention the function number for each trap).

-- 
http://mikro.atari.org

Re: [Freemint-discuss] "r" modifiers in osbind.h & falcon.h

[Thorsten O. <ad...@th...>]

On Donnerstag, 4. April 2024 12:07:55 CEST Miro Kropáček wrote:
> But that requires getting rid of those "short _a = (short)(a);" first

No, that does not matter:

$ cat foo.c

static void test(int x, int y)
{
	short _x = x;
	short _y = y;
	
        __asm__ volatile(
        "movw %0,%%sp@-\n\t"
        "movw %1,%%sp@-\n\t"
        "trap #14\n\t"
        "addq.l #4,%%sp\n"
        :
        : "ri"(_x), "ri"(_y)
        : "d1", "d2", "a0", "a1", "a2", "cc", "memory");
}

void test2(int x)
{
        test(x, 100);
}

$ m68k-atari-mint-gcc -S -O2 -fomit-frame-pointer -o - foo.c

_test2:
        move.l %a2,-(%sp)
        move.l %d2,-(%sp)
        move.l 12(%sp),%d0
        movw %d0,%sp@-
        movw #100,%sp@-
        trap #14
        addq.l #4,%sp
        move.l (%sp)+,%d2
        move.l (%sp)+,%a2
        rts

Re: [Freemint-discuss] "r" modifiers in osbind.h & falcon.h

[Miro K. <mir...@gm...>]

On Thu, 4 Apr 2024 at 10:13, Thorsten Otto <ad...@th...> 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.
>
But that requires getting rid of those "short _a = (short)(a);" first,
which is, as you recently pointed out, not a trivial thing to do.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] "r" modifiers in osbind.h & falcon.h

[Thorsten O. <ad...@th...>]

On Donnerstag, 4. April 2024 09:47:45 CEST Miro Kropáček wrote:
> What saddens me most is seeing a nice inlined function which automatically
> uses constants instead of parameters on stack and then this constant is put
> into a register. :(

Maybe the constraints could be relaxed to "ri" so that immediate constants can 
be pushed as such. But thas has to be carefully checked.

Re: [Freemint-discuss] "r" modifiers in osbind.h & falcon.h

[Miro K. <mir...@gm...>]

On Thu, 4 Apr 2024 at 08:42, Thorsten Otto <ad...@th...> wrote:

> The problem is that the SP changes while the operands are accessed. So if
> that are local variables or parameters to the function, using "g" would
> produce wrong stack pointer references.
>
Oh man, what a pain. Thanks for the demonstration example, this is indeed
quite hard to solve.


> I've also already seen that it often produces inefficient code, moving
> registers back and forth, and clobbering lots of registers that could be
> used for better cases.
>
What saddens me most is seeing a nice inlined function which automatically
uses constants instead of parameters on stack and then this constant is put
into a register. :(

-- 
http://mikro.atari.org

Re: [Freemint-discuss] "r" modifiers in osbind.h & falcon.h

[Thorsten O. <ad...@th...>]

To demonstrate this:

$ cat foo.c

void test(int x, int y)
{
	__asm__ volatile(
	"movl %0,%%sp@-\n\t"
	"movl %1,%%sp@-\n\t"
	"trap #14\n"
	"addq.l #8,%%sp\n"
	:
	: "g"(x), "g"(y)
	: "d1", "d2", "a0", "a1", "a2", "cc", "memory");
}

$ m68k-atari-mint-gcc -O2 -fomit-frame-pointer -S -o - foo.c

_test:
        move.l %a2,-(%sp)
        move.l %d2,-(%sp)
        movl 12(%sp),%sp@-
        movl 16(%sp),%sp@-
        trap #14
        addq.l #8,%sp
        move.l (%sp)+,%d2
        move.l (%sp)+,%a2
        rts

The first push (for "x") is correct. But the offset "16" for the 2nd push of 
"y" is wrong, because the sp at that time has already changed by 4.

Re: [Freemint-discuss] "r" modifiers in osbind.h & falcon.h

[Thorsten O. <ad...@th...>]

On Donnerstag, 4. April 2024 00:19:18 CEST Miro Kropáček wrote:
> They are all used as source operands to move, is there any addressing mode
> for the src operand which move would refuse and yet gcc could use it?

The problem is that the SP changes while the operands are accessed. So if that 
are local variables or parameters to the function, using "g" would produce 
wrong stack pointer references.

I've also already seen that it often produces inefficient code, moving 
registers back and forth, and clobbering lots of registers that could be used 
for better cases. But i haven't found any solution to this so far, using "r" 
seems the only way to ensure that the correct code is generated.

[Freemint-discuss] "r" modifiers in osbind.h & falcon.h

[Miro K. <mir...@gm...>]

Hi,

I've been wondering: why the modifiers in macros like:

#ifndef trap_14_wwwwww
#define trap_14_wwwwww(n,a,b,c,d,e) \
__extension__ \
({ \
register long __retvalue __asm__("d0"); \
short _a = (short)(a); \
short _b = (short)(b); \
short _c = (short)(c); \
short _d = (short)(d); \
short _e = (short)(e); \
\
__asm__ volatile \
( \
"movw %6,%%sp@-\n\t" \
"movw %5,%%sp@-\n\t" \
"movw %4,%%sp@-\n\t" \
"movw %3,%%sp@-\n\t" \
"movw %2,%%sp@-\n\t" \
"movw %1,%%sp@-\n\t" \
"trap #14\n\t" \
"lea %%sp@(12),%%sp" \
: "=r"(__retvalue) \
: "g"(n), "r"(_a), "r"(_b), "r"(_c), "r"(_d), "r"(_e) \
: __CLOBBER_RETURN("d0") "d1", "d2", "a0", "a1", "a2", "cc", "memory"); \
__retvalue; \
})
#endif

have to be specified as "r" instead of "g" ? They are all used as source
operands to move, is there any addressing mode for the src operand which
move would refuse and yet gcc could use it?

I'm even not sure why do we insist on those "short _x = (short)x"
constructs, the macro is always called with proper casts, e.g.:

#define Devconnect(src,dst,sclk,pre,proto) \
(long)trap_14_wwwwww((short)139,(short)(src),(short)(dst), \
(short)(sclk),(short)(pre),(short)(proto))

so why not benefit directly from e.g.

move.w #3,-(sp)
:
:

but doing instead this:

move.w #3,dX
move.w dX,-(sp)
:
:

?

No wonder that the experimental -mfast-call switch provides so much better
results.
-- 
http://mikro.atari.org

Re: [Freemint-discuss] Different code produced for long multiplication with contants

[Roger B. <an...@xp...>]

On 25 Mar 2024 at 12:07, Thorsten Otto wrote:

> Does anybody know the instruction time for a muls.l (32*32bit mul) on
> 68020+?
> 
BTW, I assume you looked at the user's manual(s)?  In the 68030 manual, it 
states that the *max* time for a MULS.L is 44 cycles (+ fetch effettive address 
time).  And I expect that info is the most that anyone trying to optimise a  
compiler would have.

Roger

Re: [Freemint-discuss] Different code produced for long multiplication with contants

[Roger B. <an...@xp...>]

On 25 Mar 2024 at 16:49, Thorsten Otto wrote:

> On Montag, 25. März 2024 16:29:35 CET Roger Burrows via Freemint-discuss 
> wrote:
> > If you're *really* interested, I
> > can send you the code & doc and you can convert it.
> 
> Thanks for the offer, but i think this has to be tested on real hardware, 
> since Hatari is not yet cycle exact for 030+
> 
Ah sorry, I thought you had real hardware.  I did my DIV testing on a TT.

My offer of code is still open if anyone else wants to measure this (don't have 
time myself ATM).  It does rely on there being a spare MFP timer (Timer D on 
the TT's MFP2 is what I used).

Roger

Re: [Freemint-discuss] Different code produced for long multiplication with contants

[Thorsten O. <ad...@th...>]

On Montag, 25. März 2024 16:29:35 CET Roger Burrows via Freemint-discuss 
wrote:
> If you're *really* interested, I
> can send you the code & doc and you can convert it.

Thanks for the offer, but i think this has to be tested on real hardware, 
since Hatari is not yet cycle exact for 030+

Re: [Freemint-discuss] Different code produced for long multiplication with contants

[Roger B. <an...@xp...>]

On 25 Mar 2024 at 12:07, Thorsten Otto wrote:

> Does anybody know the instruction time for a muls.l (32*32bit mul) on
> 68020+?
> 
I thought I had written a MUL execution time measurement program a while back, 
but it turns out that it does DIV instead ...  If you're *really* interested, I 
can send you the code & doc and you can convert it.  But I doubt it's worth it.

Roger

Re: [Freemint-discuss] Different code produced for long multiplication with contants

[Miro K. <mir...@gm...>]

On Mon, 25 Mar 2024 at 12:08, Thorsten Otto <ad...@th...> wrote:

> - why muls.l is used at all for 68020-60. Wouldn't the sequence of add.l,
> or the lea (%a0,%a0.l*4),%a0 be faster also for 020?
>
This is just my speculation but it may be a compromise between "it's not
*that* slow on 020+" and "it's really fast on 040/060".

-- 
http://mikro.atari.org

[Freemint-discuss] Different code produced for long multiplication with contants

[Thorsten O. <ad...@th...>]

Does anybody know the instruction time for a muls.l (32*32bit mul) on 68020+?

I wonder because different compilers produce different code for:

long x;

long test(void)
{
        return x * 5;
}

for plain m68k (all compiler versions):

_test:
        move.l _x,%d0
        move.l %d0,%d1
        add.l %d0,%d1
        add.l %d1,%d1
        add.l %d1,%d0
        rts

with -m68020 (all compiler versions):

_test:
        move.l _x,%d0
        move.l %d0,%d1
        lsl.l #2,%d1
        add.l %d1,%d0
        rts

with -m68020-60 (all compiler versions):

_test:
        moveq #5,%d0
        muls.l _x,%d0
        rts

with -mcpu=5475 (gcc 4.6.4):

_test:
        move.l _x,%a0
        lea (%a0,%a0.l*4),%a0
        move.l %a0,%d0
        rts

with -mcpu=5475 (gcc 7.x or above):

_test:
        move.l _x,%d0
        move.l %d0,%d1
        lsl.l #2,%d1
        add.l %d1,%d0
        rts

Especially im wondering:

- why m68020 and m68020-60 produces different results
- why gcc-4 produces different code for coldfire
- why muls.l is used at all for 68020-60. Wouldn't the sequence of add.l, or 
the lea (%a0,%a0.l*4),%a0 be faster also for 020?

Re: [Freemint-discuss] appl_find() behaviour

[Jo E. S. <jo....@en...>]

On Sun, 2024-01-28 at 15:00 +0100, Jo Even Skarstein wrote:
> On Sun, 2024-01-28 at 13:15 +0000, Jo Even Skarstein wrote:
> > 
> 
> > this. I will try to make a test-program to reproduce the problem.
> 
> I am able to reproduce the problem with this program (typed in,
> beware
> of typos):
> 
> #include <aes.h>
> #include <mintbind.h>
> 
> void main(void)
> {
> 	int a = 0, b = 0;
> 
> 	appl_init();
> 
> 	while (1)
> 	{
> 		long d;
> 
> 		Fselect(10, &d, &d, &d);
> 		a = appl_find((void *)(-3L << 16));
> 
> 		if (a != b)
> 		{
> 			Cconws("New top application\n\r");
> 			b = a;
> 		}
> 	}
> }
> 
> With the ec3 build an newer this program will be terminated due to a
> bus error when Pure C starts. Does not happen with previous builds.

Still struggling with this one, it turns out that when this bug kicks
in and memory protection is not enabled, the AES locks up and a reboot
is necessary. It also looks like the problem is triggered by calling
appl_find(3<<16) while or immediately after switching to another top
application. Decreasing the frequency of the appl_find call decreases
the chances of a crash, but does not remove it.

For now I have worked around this by replacing the call to appl_find
with wind_get WF_TOP/WF_OWNER calls, but this is not ideal as it does
not report the correct top application when the top application does
not have an open window.

Jo Even

Re: [Freemint-discuss] New m68k-atari-mintelf toolchain with PRG/ELF format

[Thorsten O. <ad...@th...>]

On Donnerstag, 15. Februar 2024 00:17:26 CET Vincent Rivière wrote:
> 6) gdbserver is still unavailable. I will work on it in a few weeks. Stay
> tuned.

Maybe you want to look at my branch (https://github.com/th-otto/binutils/tree/
binutils-2_41-mint or https://github.com/th-otto/binutils/tree/binutils-2_42-mint). I did some work on it already some months ago, so it can be compiled. 
However it does not work yet as expected (it seems to directly start the 
program instead of waiting for a remote gdb to attach first).

Also i've tried only network connections (with aranym), not connecting over 
serial lines.

There is also the question how to distribute it. It will compile from a 
checkout of our repos, but the "official" versions of the tar archives only 
contain the binutils directories or the gdb directories, but not both.

Re: [Freemint-discuss] Food for thought: Linux Patches Allow Kernel Tracing To Work Past Reboots/Crashes

[Thorsten O. <ad...@th...>]

On Montag, 11. März 2024 21:15:42 CET Miro Kropáček wrote:
> Having the insane (for Atari world) amounts of RAM in TT/CT60/V4S/Aranym,
> this could work well on our systems, too:
> https://www.phoronix.com/news/Linux-Tracing-Post-Reboots.

For aranym atleast, that wont work since the memory may already be cleared by 
the host. Also that assumes that we have some backtrace ability in the kernel, 
which isn't the case.

[Freemint-discuss] Food for thought: Linux Patches Allow Kernel Tracing To Work Past Reboots/Crashes

[Miro K. <mir...@gm...>]

Having the insane (for Atari world) amounts of RAM in TT/CT60/V4S/Aranym,
this could work well on our systems, too:
https://www.phoronix.com/news/Linux-Tracing-Post-Reboots.
-- 
http://mikro.atari.org

Re: [Freemint-discuss] gemma & mintelf

[Thorsten O. <ad...@th...>]

On Sonntag, 18. Februar 2024 23:30:29 CET Vincent Rivière wrote:
> As a refinement, I also put the gemma startup code into the
> .text.startup section, but this wasn't a requirement.

Your linker script still does not have the fix for the .text.startup section.

Just putting the _start symbol in that section is not enough for file formats 
like SLB that require it to be the first thing in the file. When using the 
stripex tool, the initial branch to that symbol will be removed. And the 
stripex tool should be used for such files, otherwise SLBs can't be loaded by 
older kernels that don't have the fix for the new ELF file format.

Re: [Freemint-discuss] gemma & mintelf

[Thorsten O. <ad...@th...>]

On Dienstag, 20. Februar 2024 20:25:50 CET Paul Wratt wrote:
> Some important changes in GCC 12 made for incompatible
> binaries (the ABI is different from previous versions)

Hu? What exactly is different?

Re: [Freemint-discuss] gemma & mintelf

[Paul W. <pau...@gm...>]

I guess its time for people to start using it for other programs, at
least there are a few of us on the list atm that can help with testing
on various hardware combos.

Thanks again to Vincent for "bringing AtariST development into the
future". Some important changes in GCC 12 made for incompatible
binaries (the ABI is different from previous versions), so updating to
GCC 13 is a major benefit going forward

On 2/20/24, Vincent Rivière <vin...@fr...> wrote:
> On 19/02/2024 at 11:58, Miro Kropáček wrote:
>> It's good that even such non-mainstream things like gemma are tested,
>> because it reveals forgotten/non-handled special cases in the new gcc.
>
> Hehe, gemma was just the testcase. Key feature was SLB (I should have
> mentioned it in the subject).
>
> So we have PRG/ELF working for PRG, SLB, LDG, GDB... what else?
> (I know: gdbserver. It will come.)
>
> It seems that the new mintelf toolchain and PRG/ELF file format are
> suitable for almost anything 😎
>
> --
> Vincent Rivière
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>

Re: [Freemint-discuss] gemma & mintelf

[Vincent R. <vin...@fr...>]

On 19/02/2024 at 11:58, Miro Kropáček wrote:
> It's good that even such non-mainstream things like gemma are tested, 
> because it reveals forgotten/non-handled special cases in the new gcc.

Hehe, gemma was just the testcase. Key feature was SLB (I should have 
mentioned it in the subject).

So we have PRG/ELF working for PRG, SLB, LDG, GDB... what else?
(I know: gdbserver. It will come.)

It seems that the new mintelf toolchain and PRG/ELF file format are 
suitable for almost anything 😎

-- 
Vincent Rivière

Re: [Freemint-discuss] gemma & mintelf

[Thorsten O. <ad...@th...>]

On Sonntag, 18. Februar 2024 23:30:29 CET Vincent Rivière wrote:
> but they weren't due to a typo.

Oops, my fault. Maybe i used the opcode of your first version of the mintelf 
header, and forgot to change it later.


>So I just removed that hack in the linker, and now the warning appears.

Ah, good. I already wondered whether it is a good idea to PROVIDE that symbol, 
but did not encounter any issues with it so far.

>As a refinement, I also put the gemma startup code into the 
>.text.startup section, but this wasn't a requirement.

Maybe not required after the fixes, but i think it is always a good idea to 
have the entry point at the start of the text segment. Without that, tools 
like stripex can't work.

Re: [Freemint-discuss] gemma & mintelf

[Miro K. <mir...@gm...>]

Nice investigative work!

It's good that even such non-mainstream things like gemma are tested,
because it reveals forgotten/non-handled special cases in the new gcc.

On Sun, 18 Feb 2024 at 23:31, Vincent Rivière <vin...@fr...>
wrote:

> Hi,
>
> Just a word to say that I've successfully patched gemma for the
> m68k-atari-mintelf toolchain. There was a few pitfalls.
>
> Thorsten had already done almost all the work. However, this didn't work
> out
> of the box.
>
> First, I needed to add a minor fix to the FreeMiNT kernel. The new SLB
> libraries with PRG/ELF file format were supposed to be supported, but they
> weren't due to a typo. After having found the bug, this was easy to fix:
>
> https://github.com/freemint/freemint/commit/dae5f4e6324566deeb2a47bd228ccbc9f3d512e4
>
> Next, the startup code of the gemma programs (namely, gemma.app and
> test.app) didn't work as expected. This is because they use a custom
> startup
> code placed first on the linker command-line. But due to the complex
> mintelf
> linker script, main() was actually put in first position, then the startup
> code afterwards. As a result, the programs crashed on exit, at main()
> return.
>
> How possible? There is actually a trap. If a file containing a main()
> function is compiled with gcc -O2, then gcc puts the main function into
> the
> .text.startup section. And that section is linked before the .text
> section.
> If the startup code is in the .text section... then you lose.
>
> I didn't notice that at first, because I added an experimental hack to the
> mintelf linker script. If no _start label exists, the linker uses the
> beginning of the output .text section as entry point. And normally, it
> issues a warning in that case:
> "warning: cannot find entry symbol _start; defaulting to 000000a0."
> In my first mintelf release, tried to hide that warning by automatically
> defining _start in the linker script. It worked well, but as a result, the
> entry point wasn't always the one expected (i.e. gemma programs). That
> idea
> was finally a bad one.
>
> So I just removed that hack in the linker, and now the warning appears.
>
>
> https://github.com/vinriviere/m68k-atari-mint-binutils-gdb/commit/aabcdc9984ceaafa130a598c333481bd0116b38a
>
> The easy fix is just to add a _start global label at the beginning of
> programs using a custom startup code. There aren't much. This immediately
> fixes the issue. As a refinement, I also put the gemma startup code into
> the
> .text.startup section, but this wasn't a requirement.
>
>
> https://github.com/freemint/gemma/commit/de3e3e49eaf80eaa305ee57f36188149b822a207
>
> https://github.com/freemint/gemma/commit/729c078a0666b81d41de6c9f721028efb7c070e5
>
> Now everything works flawlessly.
> Thank you Thorsten for your initial mintelf work on gemma. I only needed
> to
> fix the above issues.
>
> I took this opportunity to update the cross-tools mintelf binaries:
> http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/
>
> It seems that the new PRG/ELF format works everywhere 😊
>
> PS: During my test I found a different issue with the SLBPATH variable. I
> opened a specific issue for that:
> https://github.com/freemint/gemma/issues/7
>
> --
> Vincent Rivière
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>


-- 
http://mikro.atari.org

[Freemint-discuss] gemma & mintelf

[Vincent R. <vin...@fr...>]

Hi,

Just a word to say that I've successfully patched gemma for the 
m68k-atari-mintelf toolchain. There was a few pitfalls.

Thorsten had already done almost all the work. However, this didn't work out 
of the box.

First, I needed to add a minor fix to the FreeMiNT kernel. The new SLB 
libraries with PRG/ELF file format were supposed to be supported, but they 
weren't due to a typo. After having found the bug, this was easy to fix:
https://github.com/freemint/freemint/commit/dae5f4e6324566deeb2a47bd228ccbc9f3d512e4

Next, the startup code of the gemma programs (namely, gemma.app and 
test.app) didn't work as expected. This is because they use a custom startup 
code placed first on the linker command-line. But due to the complex mintelf 
linker script, main() was actually put in first position, then the startup 
code afterwards. As a result, the programs crashed on exit, at main() return.

How possible? There is actually a trap. If a file containing a main() 
function is compiled with gcc -O2, then gcc puts the main function into the 
.text.startup section. And that section is linked before the .text section. 
If the startup code is in the .text section... then you lose.

I didn't notice that at first, because I added an experimental hack to the 
mintelf linker script. If no _start label exists, the linker uses the 
beginning of the output .text section as entry point. And normally, it 
issues a warning in that case:
"warning: cannot find entry symbol _start; defaulting to 000000a0."
In my first mintelf release, tried to hide that warning by automatically 
defining _start in the linker script. It worked well, but as a result, the 
entry point wasn't always the one expected (i.e. gemma programs). That idea 
was finally a bad one.

So I just removed that hack in the linker, and now the warning appears.

https://github.com/vinriviere/m68k-atari-mint-binutils-gdb/commit/aabcdc9984ceaafa130a598c333481bd0116b38a

The easy fix is just to add a _start global label at the beginning of 
programs using a custom startup code. There aren't much. This immediately 
fixes the issue. As a refinement, I also put the gemma startup code into the 
.text.startup section, but this wasn't a requirement.

https://github.com/freemint/gemma/commit/de3e3e49eaf80eaa305ee57f36188149b822a207
https://github.com/freemint/gemma/commit/729c078a0666b81d41de6c9f721028efb7c070e5

Now everything works flawlessly.
Thank you Thorsten for your initial mintelf work on gemma. I only needed to 
fix the above issues.

I took this opportunity to update the cross-tools mintelf binaries:
http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/

It seems that the new PRG/ELF format works everywhere 😊

PS: During my test I found a different issue with the SLBPATH variable. I 
opened a specific issue for that:
https://github.com/freemint/gemma/issues/7

-- 
Vincent Rivière