A1222 support in the SDK and problems

	Bottom Previous Topic Next Topic
Register To Post

« 1 2 (3) 4 »

FlynnTheAvatar

Re: A1222 support in the SDK and problems

Posted on: 2024/6/29 13:45 #41

Just popping in

@Maijestro

The log file is in ffbuild/config.log.

That is not a standard location, normally it should be in the same directory where you ran configure.

Maijestro

Re: A1222 support in the SDK and problems

Posted on: 2024/6/29 14:20 #42

Just can't stay away

@FlynnTheAvatar

Quote:

FlynnTheAvatar wrote:@Maijestro

The log file is in ffbuild/config.log.

That is not a standard location, normally it should be in the same directory where you ran configure.

Ok I tried again with version 6.1.1 of FFMPEG and get the following error message "Unknown OS 'amigaos'." probably I have to set a target.

But it doesn't matter at the moment as long as I can't build the compile with "SPE" optimizations at all. The normal compile would make no sense here as there is already a FFMPEG version 6.1.1 on Os4Depot.

log FFMPEG Build:


mktemp -u XXXXXX

configure[4590]: mktemp: not found

test_ld cc

test_cc

BEGIN /T/ffconf....1783026048/test.c

    1    int main(void){ return 0; }

END /T/ffconf....1783026048/test.c

gcc -c -o /T/ffconf....1783026048/test.o /T/ffconf....1783026048/test.c

gcc -o /T/ffconf....1783026048/test /T/ffconf....1783026048/test.o

check_cxxflags -std=c++11

test_cxx -std=c++11

BEGIN /T/ffconf....1783026048/test.cpp

    1    int x;

END /T/ffconf....1783026048/test.cpp

g++ -D_ISOC99_SOURCE -D__STDC_CONSTANT_MACROS -std=c++11 -c -o /T/ffconf....1783026048/test.o /T/ffconf....1783026048/test.cpp

test_cflags_cc -std=c11 ctype.h __STDC_VERSION__ >= 201112L

test_cc -std=c11

BEGIN /T/ffconf....1783026048/test.c

    1    #include <ctype.h>

    2    #if !(__STDC_VERSION__ >= 201112L)

    3    #error "unsatisfied condition: __STDC_VERSION__ >= 201112L"

    4    #endif

END /T/ffconf....1783026048/test.c

gcc -D_ISOC99_SOURCE -std=c11 -c -o /T/ffconf....1783026048/test.o /T/ffconf....1783026048/test.c

check_cppflags -D_FILE_OFFSET_BITS=64

test_cpp -D_FILE_OFFSET_BITS=64

BEGIN /T/ffconf....1783026048/test.c

    1    #include <stdlib.h>

END /T/ffconf....1783026048/test.c

gcc -D_ISOC99_SOURCE -std=c11 -D_FILE_OFFSET_BITS=64 -E -o /T/ffconf....1783026048/test.o /T/ffconf....1783026048/test.c

check_cppflags -D_LARGEFILE_SOURCE

test_cpp -D_LARGEFILE_SOURCE

BEGIN /T/ffconf....1783026048/test.c

    1    #include <stdlib.h>

END /T/ffconf....1783026048/test.c

gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -std=c11 -D_LARGEFILE_SOURCE -E -o /T/ffconf....1783026048/test.o /T/ffconf....1783026048/test.c

check_host_cflags -std=c99

test_host_cc -std=c99

BEGIN /T/ffconf....1783026048/test.c

    1    int x;

END /T/ffconf....1783026048/test.c

gcc -std=c99 -c -o /T/ffconf....1783026048/test.o /T/ffconf....1783026048/test.c

check_host_cflags -Wall

test_host_cc -Wall

BEGIN /T/ffconf....1783026048/test.c

    1    int x;

END /T/ffconf....1783026048/test.c

gcc -std=c99 -Wall -c -o /T/ffconf....1783026048/test.o /T/ffconf....1783026048/test.c

check_host_cflags -O3

test_host_cc -O3

BEGIN /T/ffconf....1783026048/test.c

    1    int x;

END /T/ffconf....1783026048/test.c

gcc -std=c99 -Wall -O3 -c -o /T/ffconf....1783026048/test.o /T/ffconf....1783026048/test.c

test_code cc  int test[2*(sizeof(void *) > 4) - 1]

test_cc

BEGIN /T/ffconf....1783026048/test.c

    1    int main(void) { int test[2*(sizeof(void *) > 4) - 1]; return 0; }

END /T/ffconf....1783026048/test.c

gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -std=c11 -c -o /T/ffconf....1783026048/test.o /T/ffconf....1783026048/test.c

/T/ffconf....1783026048/test.c: In function 'main':

/T/ffconf....1783026048/test.c:1:22: error: size of array 'test' is negative

 int main(void) { int test[2*(sizeof(void *) > 4) - 1]; return 0; }

                      ^~~~

Unknown OS 'amigaos'.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE

jabirulo

Re: A1222 support in the SDK and problems

Posted on: 2024/6/29 16:16 #43

Just can't stay away

@Maijestro, but if you build "without SPE" it builds correctly?

if yes, the it's a matter to "find" the correct "switches/options". but no friggin' idea TBH.

Maijestro

Re: A1222 support in the SDK and problems

Posted on: 2024/6/29 17:21 #44

Just can't stay away

@jabirulo

Quote:

jabirulo wrote:@Maijestro, but if you build "without SPE" it builds correctly?

if yes, the it's a matter to "find" the correct "switches/options". but no friggin' idea TBH.

Yes, I wanted to build it for testing purposes with a simple "./configure" without SPE optimized functions, but even that fails.

I'm also not sure if after ",/configure" further options like "-taget amigaos" or similar have to be specified.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE

LiveForIt

Re: A1222 support in the SDK and problems

Posted on: 2024/6/29 18:19 #45

Home away from home

@Maijestro

Configure is Lnux sh script,
AmigaOS is barely an existing OS.
you might need to generate makefiles for linux
target or posix and modify the makefile and makefile.in etc script as needed.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.

Maijestro

Re: A1222 support in the SDK and problems

Posted on: 2024/6/29 20:34 #46

Just can't stay away

@all

Ok I give up, the best would probably be a cross compiler over Linux, but I only have the possibility to use MacOs, so I'm out for now.

If there is someone who could provide a clip4 version of FFMPEG including "SPE" optimization that would be excellent. If not it's ok and I'll use the things as they are available.

Thanks anyway everyone for the help.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE

jabirulo

Re: A1222 support in the SDK and problems

Posted on: 2024/6/29 22:05 #47

Just can't stay away

@Maijestro
dont give up!!!
I know is a pita sometimes, but...

using crosscompiler (via docker or whatever):
./configure --host=ppc-amigaos --target=ppc-amigaos

https://www.amigans.net/modules/newbb/viewtopic.php?topic_id=8122

smarkusg

Re: A1222 support in the SDK and problems

Posted on: 2024/6/30 22:09 #48

Not too shy to talk

@Maijestro

Quote:

If there is someone who could provide a clip4 version of FFMPEG including "SPE" optimization that would be excellent. If not it's ok and I'll use the things as they are available.

I can build you ffplay under SPE with clib4 only with flags under CPU. I don't have access to the A1222 I am not able to make you other things under SPE and even check it.
The code generated under SPE will not work for me.

It is a pity that the A1222 has been announced for so many years, even some people had access to it and nobody was interested in its life after it was released.

arfcarl

Re: A1222 support in the SDK and problems

Posted on: 2024/7/1 11:34 #49

Just popping in

@smarkusg

It’s released and sells a lot (multiple of tens, maybe hundreds). There’s definitely some interest.

flash

Re: A1222 support in the SDK and problems

Posted on: 2024/7/1 13:08 #50

Just popping in

Someone has to release a new SDK with full support for A1222 to let new apps, and rebuild of the existing ones, to take advantage of new vector unit, reduce slow fpu emulation and avoid crashes/gurus/grim reapers.
I hope also to have full integration of afx clib in next release.

Memento audere semper!

Maijestro

Re: A1222 support in the SDK and problems

Posted on: 2024/7/1 16:15 #51

Just can't stay away

@flash

Until recently I used AmigaOs4.1 exclusively on my MacStudio with Qemu and that was for almost 2 years before I bought the A1222. Many things work just as quickly as the experience I had with Qemu.

But of course there are also things that simply work worse, especially when they come into contact with emulation or software that is not compatible. Everything that is ported and used with Clib4 works really well.

I agree with you that a customized SDK for the A1222 will be essential, we should not forget that the A1222 may be the last PPC hardware released for AmigaOs4.1, so I think it is all the more important that the last platform should be supported, even if Tabor's actual call is unfounded. But like everything, it will take time, a lot of time....

So I accept things as they are and I knew there would be limitations anyway, but the box is still really fun.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE

sailor

Re: A1222 support in the SDK and problems

Posted on: 1/11 14:13 #52

Not too shy to talk

@doozQuote:

dooz wrote:@sailor
...
I tested all this in A1222 and results are great in some games, some not (too slow to play). I even amanged to get Quake Darkplaces working with more than 20 fps under LTE (Quake uses a lot FPU code). Quake darkplaces must be started with benchmark switch (otherwise it doesnt work, also game must be started from previous saved game position - if you have one from other Amiga system):

stack 9000000
darkplaces-sdl -benchmark -widht 640 -height 480

Lots of things to investigate and play around with A1222 Real SPE optimized games will work excellent because SPE FPU performance is fast. This is when FPU is used in games - then I guess the real thing is to transfer all the calculations on the graphic card...not using much of FPU.

Here I have A1222 with Radeon RX 580. It works great.

-dooz

Please, have somebody share Darkplaces save game? Ideally the same beginning. I want to try it on A1222, like @dooz adviced.
Unfortunatelly, it do not run on my X1000 to produce save game.

AmigaOS3: Amiga 1200
AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000
MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad

sailor

Re: A1222 support in the SDK and problems

Posted on: 1/21 19:16 #53

Not too shy to talk

I have still problem with SPE (-mcpu=8540 -mspe -mabi=spe -mfloat-gprs=double) double variables alignment:

If I declared double variables like globals, they are aligned allways to 4 Bytes ( I even used __aligned__ attribute). If I declared them inside main(), they are aligned correctly to 8 Bytes. SPE needs 8 byte alignment.


double T1 __attribute__ ((aligned (8)));

double T2 __attribute__ ((aligned (8)));

...

int main (int argc, char *argv[])

{

    double T;

...

printf("Address T:%p\n", &T);

printf("Address T1:%p\n", &T1);

printf("Address T2:%p\n", &T2);

Output is:


Address T:0x6c361c68

Address T1:0x6bb4b63c

Address T2:0x6bb4b62c

T is 8 Byte alligned, T1 + T2 4 Byte aligned, __align__ not works here

Program will crash ( generate error of type alignment), if T1 or T2 is used, T is OK.

I tried -malign-power / -malign-natural and -mstrict-align / -mnostrict-align options.

Any idea, how to solve it?

LiveForIt

Re: A1222 support in the SDK and problems

Posted on: 1/21 20:10 #54

Home away from home

@Maijestro

I think the open power laptop might be the next AmigaOS4 machine, you have the correct people working on it, to make that happen.

Currently all we know, they making sure it can boot linux for now, but once that’s done, Acube-Systems know how to write drivers for AmigaOS4, Hyperion simply need to provide a license, or allow it to happen. That’s in Hyperion’s interest as they now well licenses to end users. AEON will be able to sell drivers and enchanter, again a win win.

The QorIQ T series of CPU’s are a power house, compared to some of the chips we are used to.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.

salass00

Re: A1222 support in the SDK and problems

Posted on: 1/21 22:44 #55

Just can't stay away

@sailor

Quote:

If I declared double variables like globals, they are aligned allways to 4 Bytes ( I even used __aligned__ attribute). If I declared them inside main(), they are aligned correctly to 8 Bytes. SPE needs 8 byte alignment.

I encountered a similar problem when testing libcfsl code (SPE optimized versions of some standard string functions) in that the static LUTs (declared in assembler code here) would not always be aligned correctly when loaded even though .align was used in the code. I filed a bug report for this for elf.library but IIRC the verdict was that the issue was somewhere in the gcc linker script.

sailor

Re: A1222 support in the SDK and problems

Posted on: 1/22 7:54 #56

Not too shy to talk

@salass00Quote:

salass00 wrote:
I encountered a similar problem when testing libcfsl code (SPE optimized versions of some standard string functions) in that the static LUTs (declared in assembler code here) would not always be aligned correctly when loaded even though .align was used in the code. I filed a bug report for this for elf.library but IIRC the verdict was that the issue was somewhere in the gcc linker script.

Oh, it is not good news. As it concerns gcc v.6.4 it probably never be fixed.

Are there some workaround how to align global variables?
Or some advice ( a little bit for blondes ), how to fix this in assembler?
In normal code I can replace long doubles with pointers to them, or simply allocate piece of memory and work in it, but in my case it is SPE-version of standardized benchmarks, so I don't want modify code logic, because results will be uncomparable with powerpc and others benchmark versions.

Edited by sailor on 2025/1/22 10:48:15

flash

Re: A1222 support in the SDK and problems

Posted on: 1/22 10:09 #57

Just popping in

@sailor

..try to declare them as APTR (void *) and casting vars to double using pointer (*) and address (&) operators.
You shoud not got penality in benchmarks.

salass00

Re: A1222 support in the SDK and problems

Posted on: 1/22 15:24 #58

Just can't stay away

@sailor

I don't think I tested it since I thought it was an issue with how the executable was loaded at the time, but you could try compiling the object files with ppc-amigaos-gcc-6.4.0 and then linking them with a newer version.

This is how the graphics.library.kmod with SPE support is created. Only the source files that need it are compiled with ppc-amigaos-gcc-6.4.0 and ppc-amigaos-gcc is used to compile everything else and for linking the final executable.

balaton

Re: A1222 support in the SDK and problems

Posted on: 1/22 15:33 #59

Quite a regular

@sailor
According to gcc docs aligned attribute is for structs so maybe you could try putting your vars in a struct? Something like


struct vars {

  double T1,

  double T2

} __attribute__ ((aligned (8)));

struct vars globals;

...

globals.T1 = 1.0;

or the doc also mentions it might work for typedef so you can try


typedef double spe_double __attribute__ ((aligned (8)));

spe_double T1;

(Quick English lesson for blondes: It works -> it does work -> it does not work -> it doesn't work. "Not works" does not work in English.

)

joerg

Re: A1222 support in the SDK and problems

Posted on: 1/22 15:40 #60

Just can't stay away

@sailor
Quote:

Oh, it is not good news. As it concerns gcc v.6.4 it probably never be fixed.

The ld linker scripts are text files and easy to fix if there is something wrong in them, you don't need to rebuild binutils (ld) to fix it.

@salass00
Quote:

I don't think I tested it since I thought it was an issue with how the executable was loaded at the time, but you could try compiling the object files with ppc-amigaos-gcc-6.4.0 and then linking them with a newer version.

This is how the graphics.library.kmod with SPE support is created. Only the source files that need it are compiled with ppc-amigaos-gcc-6.4.0 and ppc-amigaos-gcc is used to compile everything else and for linking the final executable.

Simply make a diff of the (broken) 6.4.0 linker script with the one of a (newer?) working version. Whatever the working version does differently should work with the 6.4.0 binutils ld as well.

@balaton
The alignment in the sources and object files seems to be correct anyway, and using different alignment methods doesn't help if there are bugs in the script.ld causing wrong alignment in the ELF executable.
__attribute__((aligned(x))) works for simple types like int and float as well, not only for struct/union.

Edited by joerg on 2025/1/22 16:00:28

Register To Post	« 1 2 (3) 4 »
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )