have you seen this?

@kas1e

If no one has checked this before and it is not a problem for you
Maybe someone will also find such information useful.

Thank you

@kas1e
Quote:I guess it's about 100 times slower if unaligned FPU accesses have to be emulated by an alignment exception handler.
Unaligned FPU accesses, for example 2 byte aligned float or 4 bytes aligned double, which do not cause an alignment exception (on some CPUs) are slower than aligned ones as well, but only very little.

For example my powerpc.library includes a complete alignment exception handler because WarpOS executables were using the old AmigaOS 1.x-3.x m68k HUNK executable format which can't guarantee correct alignment for the PPC parts.

The Sam440/460 AmigaOS 4.x kernels include a partial alignment exception handler because the 405 with it's "external" FPU has an additional alignment requirement other PowerPC CPU's don't have: FPU accesses must never cross a cache line boundary.
For example a 4 byte aligned 64 bit double access which works on all other PowerPC CPUs, at least the supported G2, G3 and G4 ones, doesn't on Sam440/460 if the first 4 bytes are in one and the 2nd 4 bytes in another cache line.

I don't know anything about X1000 (POWER, not PowerPC, CPU), X5000 (maybe similar to G2/G3/G4, but OTOH it's a 64 bit CPU) and A1222 (no FPU) and if or if not the AmigaOS 4.x kernels for those systems include an alignment exception handler.

I has to be tested on real hardware, I very much doubt UAE and QEmu check for unaligned FPU accesses and cause a guest alignment exception if the host CPU can access it without alignment exception.

@HunoPPC

yep, same here, but if I add inside object.h (IIRC)
#pragma pack(2)
then such crash/alignment issue "goes down" to line ~76 approx.

@jabirulo

Can you share what you added in object.h ?

@SinanSam460

Not on my miggy right now (but it was just for testing). IIRC at top object.h:
#pragma pack(2)

or maybe #pragma pack(4)

and at bottom:
#pragma pack()

EDIT: forget this silly post, re-tested and got same line (58) crash/allignment issue.

@joerg
Can you by brief look on this : https://github.com/phoboslab/wipeout-r ... 45e7/src/wipeout/object.c

see what kind of alignment issues this have ? I assume there both packing and unaligned memory access issues

@kas1e
Even if the alignment in struct Object and the code is correct you may still get unaligned accesses if for example platform_load_asset(name, &length) returns an odd address (all CPUs) or something not a multiple of 8 (only a problem on some CPUs like 440/460).

Don't try to use something like #pragma pack(2) since it will reduce the alignment, for example of double from 8 to 2 bytes.

In case https://sourceforge.net/p/adtools/bugs/14/ is still not fixed (the ticket isn't closed) make sure you have -mstrict-align in your CFLAGS.
Or use a version of GCC which still worked correctly even without it (2.95.x, 3.4.x, maybe 4.0.4) instead of newer versions.

@kas1e

IMO is not in object.c the problem, the problem is that author decided to use its own memory management (sort of) in mem.c/.h
Maybe to make it easier or dunnot.

@all

Here the vidéo :
On x1000 r7

@all

And the executable test not finish
https://wetransfer.com/downloads/d4db8 ... email&utm_source=sendgrid

@all

Makefile with GCC11 just working on my X1000 here

CC ?= gcc
EMCC ?= emcc
UNAME_S := amigaos4
UNAME_O := amigaos4
RENDERER = GL_LEGACY
USE_GLX ?= false
DEBUG ?= false
USER_CFLAGS ?=

L_FLAGS ?= -lm
C_FLAGS ?= -athread=native -DGLEW_STATIC -std=gnu99 -Wall -Wno-unused-variable -mstrict-align $(USER_CFLAGS)

ifeq ($(DEBUG), true)
C_FLAGS := $(C_FLAGS) -g
else
C_FLAGS := $(C_FLAGS) -O3 -mstrict-align
endif


# Rendeder ---------------------------------------------------------------------

ifeq ($(RENDERER), GL)
RENDERER_SRC = src/render_gl.c
C_FLAGS := $(C_FLAGS) -DRENDERER_GL
else ifeq ($(RENDERER), GL_LEGACY)
RENDERER_SRC = src/render_gl_legacy.c
C_FLAGS := $(C_FLAGS) -DRENDERER_GL_LEGACY
else ifeq ($(RENDERER), SOFTWARE)
RENDERER_SRC = src/render_software.c
C_FLAGS := $(C_FLAGS) -DRENDERER_SOFTWARE
else
$(error Unknown RENDERER)
endif

ifeq ($(GL_VERSION), GLES2)
C_FLAGS := $(C_FLAGS) -DUSE_GLES2
endif


# AmigaOS4 ------------------------------------------------------------------------

ifeq ($(UNAME_S),amigaos4)
C_FLAGS := $(C_FLAGS)
C_FLAGS := $(C_FLAGS) -I/local/newlib/include
L_FLAGS := $(L_FLAGS) -L/local/newlib/lib
L_FLAGS_SDL = -lSDL2egl_wrap -legl_wrap -lauto -lm
CC = gcc

@all

New version delivred this week-end

Beta Beta Beta Work In Progress please update immediately your all games/API after this new release

LibEGL_wrap Version 0.7.20 2023

Minimal required:
Warp3DNova.library Version 54 revision 16
ogles2.library Version 3 revision 3

INTRO: This library was designed as an all-in-one system to be able to make games and to be able to allow easy ports for our AmigaOS4 system
Don't hesitate to get started and let me know of any problems or missing functions so that it can become a powerful development kit


EGL can be implemented on multiple operating systems and now on native AmigaOS4.
Implementations may also choose to allow rendering into specific types of EGL surfaces via other supported native rendering APIs (here OpenglES 2.0 for AmigaOS4.x).
Mechanisms for creating rendering surfaces (windows, pbuffers, pixmaps) onto which client APIs can draw and share.
Methods to create and manage graphics contexts for client APIs.
Ways to synchronize drawing by client APIs as well as native platform rendering APIs.
The EGLStreams extension provides a powerful but easily programmed API to control how a stream of images flow between AmigaOS4 OpenglES 2.0 APIs to enable advanced applications such as Augmented Reality with full hardware acceleration.
Include now GL4es created by PtitSeb (https://github.com/ptitSeb/gl4es), The OpenGL Extension Wrangler Library 'Glew' (https://glew.sourceforge.net/) ported by HunoPPC, image decoder PNG/JPEG/BMP/TGA by HunoPPC, sound engine by HunoPPC, AmigaInput lowlevel by HunoPPC,GUI by HunoPPC,SDL1, SDL2 and SDL_image by HunoPPC, GLUes and other small stuffs by HunoPPC.

Documentation is unfinished Work In Progress for porting your work or any games to the web

Please use a new Prefs GUI on your SYS:Prefs/ for configure your EGL_wrap and GL4es libraries
Please use ans test all samples on this folder for mecanism of my EGL_library.
Other games using the GL4es library can take advantage of my Prefs GUI, use a GL4es part on GUI and enjoy!!

Install library and Prefs:
Just launch script Install "LIB_EGL to SYS and Prefs" on libegl_wrap and enjoy!!
For SDK launch script "copy LIB_EGL to SDK"

/*---------------------------------------------SDL1-----------------------------------------------------------*/

For Projects GLUES SDL GL (no native, use gl4es) please link with this .h:

#include <EGLSDL/SDL.h>
#include <EGLSDL/SDL_opengl.h>

Or

#include "EGLSDL/SDL.h"
#include "EGLSDL/SDL_opengl.h"


If you use GLUES on SDL add this:

#include "EGLSDL/SDL.h"
#include "EGLSDL/SDL_opengl.h"
#include "EGL/glues.h"

Linked by: -lSDLegl_wrap -legl_wrap -lauto

IMPORTANT: do not use #include "SDL/SDL_opengl.h" (is for minigl) use #include "EGLSDL/SDL_opengl.h" and for the others originals headers no problems, use this.
Do not use `sdl-config --cflags`option please on your makefile
Use `eglsdl-config --cflags`option on your makefile
Do not use -use-dynld

/*---------------------------------------------SDL2-----------------------------------------------------------*/
For Projects GLUES SDL2 GL (no native, use gl4es) please link with this .h:

#include <EGLSDL2/SDL.h>
#include <EGLSDL2/SDL_opengl.h>

Or

#include "EGLSDL2/SDL.h"
#include "EGLSDL2/SDL_opengl.h"


If you use GLUES on SDL2 add this:

#include "EGLSDL2/SDL.h"
#include "EGLSDL2/SDL_opengl.h"
#include "EGL/glues.h"

Linked by: -lSDL2egl_wrap -legl_wrap -lauto

IMPORTANT: do not use #include "SDL2/SDL_opengl.h" (is for minigl) use #include "EGLSDL2/SDL_opengl.h" and for the others originals headers no problems, use this.
Do not use `sdl2-config --cflags`option please on your makefile
Use `egl2sdl-config --cflags`option on your makefile
Do not use -use-dynld

/*--------------------------------------------Native------------------------------------------------------------*/

For Projects EGL GLUES OPENGLES (native, use opengles 2.0) please link with this .h:

#include "EGL/egl.h"
#include "EGL/glues.h"

Linked by: -legl_wrap -lauto

IMPORTANT: Do not use -use-dynld

/*---------------------------------------------GLEW-----------------------------------------------------------*/
For Projects GLEW please link with this .h:

#include "EGL/glew.h"

Linked by: -legl_wrap -lauto

IMPORTANT: Do not use -use-dynld

/*-------------------------------------------Releases-----------------------------------------------------------*/
Version 0.7.20:
* Now!! all libraries are STATIC, IMPORTANT: don't forget to delete your old dynamic libraries
* Added The OpenGL Extension Wrangler Library 'Glew' includes and package for SDK
* Updated Gl4ES
* Updated GUI
* Added new icons into the GUI

@HunoPPC

Niceee!!
For wipEout any chance for us poor users with old gfx cards?

@HunoPPC

I still get an alignment error while loading the game on my X5000.

@samo79
Yes my friend
On version for minigl and one version for egl_wrap
Just the problem of allignment on sam440 and x5000 ;-(

HunoPPC

@geennaam
Yes! It’s normal… just working on X1000 for this time

HunoPPC

@geennaam
According to https://www.amigans.net/modules/newbb/ ... id=142807#forumpost142807 the X1000 not only supports unaligned FPU accesses, but even FPU accesses to odd addresses.
All other CPUs supported by AmigaOS 4.x don't (except for the P1022 FPU emulator maybe, but I don't know anything about it).
I could release a standalone alignment exception handler from the code I used in my powerpc.library: All software with alignment bugs would work that way on any CPU, but extremely slow.

@joerg

It would be really excellent to try it first to see what it gives

HunoPPC

@kas1e
Quote:

I checked on Sam460 emulation under QEMU and Pegasos 2 with your test program.

Apple M1 - Problem does not occur.

@joerg
Thanks for the tip "-mstrict-align" I was convinced that this was fixed definitively since gcc-10.

@samo79
Quote:

Just what @kas1e @jabirulo @SinanSam460 are working on .... PPC code compatibility (I'm a fast learner ;-} )
Compilation under minigl works very well, no need for GL4ES,EGL...