@cdimauro

Quote:

cdimauro wrote: Just by case (well, not really: I've some interest), yesterday I've spent a lot of time tinkering on VBCC, VLink and VAsm, generating cross-compilers/assemblers at least for 68k,

Excellent. Can you compile A09 optimized for smallest size and also for fastest operation, then tell us the file sizes? Should be easy as it's only a single .c file.

Quote:

What came out is that VBCC and VASM are very very strong / good for 68k and poor / very bad for i386/x86 and specially for ARM. VBCC basically supports only the 80386 + the x87 FPU. There's no trace of newer architectures, SIMD, etc.

So it could make the Amiga look better! Cheating? Or a way to level the playing field in retro computing. I'm sick of hearing about how the Amiga wasn't as good as the PC because we didn't have good compilers for it.

Quote:

At least their cores are / should be small. On the extreme embedded market that's what is important.

I love working at the extreme low end where every byte and cycle counts. One project involved using an ATmega1284 to produce a programmable character generator 'ROM' for the Mattel Aquarius. Running it at 25MHz I managed to get the timing accurate to 40ns (1 CPU cycle) which was just good enough. No subroutines, no interrupts, stack not initialized. All variables held in registers with RAM used only for storing and reading out character patterns. Coded in AVR asm of course, you wouldn't attempt this in C! Most people would use a faster ARM CPU, but then they would need several more chips to power it with 3.3V and level shift the logic signals.

@matthey

Quote:

matthey wrote: cdimauro Quote: That's for SASC. Other compilers could do (very) different. You can't take a single case and generalize to the overall situation... I know vasm uses different peephole optimizations depending on the -O optimization selection and I expect vbcc will stop loop unrolling and any function inlining that would increase code size. This should make a big difference which is, or at least was, expected with GCC for the 68k back when it was better supported.

Maybe for 68k. I haven't checked thoroughly, but I don't recall peephole optimizers for VBCC and Vasm; anyway, it's not important now.
Quote:

cdimauro Quote: Which doesn't work when talking about code density studies. That's very simple to understand: you need to fix ALL variables EXCEPT one (the architectures to be compared). That's why such studies use a compiler like GCC (some also use LLVM) which is available for the benchmarked architectures, which has an overall good support for all of them. Have you ever seen Intel's compiler used on such studies? Rarely (usually when the studies involve benchmarking different compilers), because of the above. However you should question yourself which compiler gives (on average) better result for x86 and x64 architectures and you can give yourself the easy answer. Which, unfortunately, does NOT support your statement... Using the same cross compiler for a benchmark reduces the number of variables but there is a big difference in compiler support for different architectures. There is also an over reliance on GCC which may have flaws for particular targets, especially less supported ones. It would be interesting to compare a basket of compiled executables for a target from any source, especially if one of them has a better result than from GCC. It is easier to spot and compare a good compiled result with -Os than with -On and any better result sets a new standard. Optimizing with -Os is more common for embedded use where GCC may not be the best compiler. Vbcc is targeted more at embedded use but it is hit and miss.

Indeed. It's the usual problem of the level of maturity/support of compilers for specific architectures: less used/known ones receive less updates and their quality isn't a the same level of mainstream ones.
Quote:

cdimauro Quote: Just by case (well, not really: I've some interest), yesterday I've spent a lot of time tinkering on VBCC, VLink and VAsm, generating cross-compilers/assemblers at least for 68k, i386/x86 and ARM (which to me are the most important architectures nowadays. I haven't setup anything for PowerPC for this reason) and I've also tinkered and inspected their sources (VBCC and VAsm, specifically. VLink looks like architectures independent). What came out is that VBCC and VASM are very very strong / good for 68k and poor / very bad for i386/x86 and specially for ARM. VBCC basically supports only the 80386 + the x87 FPU. There's no trace of newer architectures, SIMD, etc.. VAsm supports even the x64, but only up to the first architecture and it's also incomplete (a lot of stuff is missing). ARM support... well... no comment: I've just tried to compile the simple Fibonacci and VBCC generated an empty file... I haven't check VAsm, anyway (because I've no source generated to be tested and I was too lazy to try something else). Even checking at their source codes, VBCC has 1.5 more for 68k than for i386, whereas VAsm has 2.5 more for 68k than for x86. It's crystal clear that its target is 68k. ARM support was not working the last I heard. Yes, it is strange for a compiler targeting embedded use. ARM is more difficult to support than it first appears. There are essentially 4 ISAs with different modes and many extensions and variants until AArch64 which is standardized but huge. It would be difficult to compete with the support in big compilers.

Yes, but ARM should be much easier to support: it's a L/S architecture and at least ARM32 and AArch64 (besides the many instructions) should be simple to support. Thumb/-2 is variable length and might require a bit of more work, but this ISA isn't so much complicated.

Anyway, it requires some ARM expert & passionate to add such support: it's evident that the guys working on VBCC/Vasm (but I haven't check the latter for assembly sources) aren't interested on those ISAs.
Quote:

Vbcc has actually become as much of a niche market compiler for odd targets as it has for embedded use. There needs to be interest, cooperation and incentive to support a target. PPC is supported well as Volker worked with PPC in the automotive embedded field. Volker and Frank are 68k Amiga users too. The x86(-64) support is minimal but adequate for cross compiling and testing.

VBCC has no x64 support. VAsm has started some, but it's incomplete.

Actually VBCC only supports 80386 + FPU and VAsm supports x86 up to the first x64 ISA (but this isn't complete).
Quote:

They could use an x86(-64) expert if you want to volunteer to improve it while implementing its replacement.

Let's see. Actually I'm tinkering with VAsm for NEx64T, because without an assembler you can do nothing with an architecture.

However and since it's a superset of x86/x64, it requires that the latters to be improved as well. IIF I'll continue on this direction, then I might contribute to VAsm: it entirely depends if I'm able to get some results in short time (otherwise I've to evaluate different solutions).
Quote:

cdimauro Quote: VBCC is good because it's a very small compiler and adding a backend for a new architecture (or enhancing an existing one) requires much less effort compared to LLVM and GCC, but the results are also very limited (because you can make benchmarks mostly only against 68k, which is the most advanced architecture available). Vasm is more or less the same. The lack of dependencies is one of the biggest advantages. Vbcc can be downloaded and recompiled with itself without downloading other software packages. The compiler frontend is modern and sophisticated enough. It's not a good sign for the future that the 68k and PPC are the most mature backends but it has been good for the (cursed?) Amiga.

Definitely. It's very small and it's really nice from this PoV. And it's unbelievable how much can do its frontend with so limited code: great work!
Quote:

cdimauro Quote: Unfortunately their source code doesn't look good: it's difficult to read because its terse, with a few or no comments (many are in German! But it's not a bit problem, because I understand something), scarse documentation. And, what's even worse is that... there's no test suite for them! So, you change something and then you've to compile and check yourself if the produced output is what you expect. That's really terrible: it's like developing at the Stone Age time! Anyway, maybe Vasm could be worth a try: it's simple enough and adding some test suite shouldn't be a big problem for me (that's what I've did in the last two decades. And Python helps a lot here). Volker's C code is all bunched together and not to my liking either. He is a doctor and there is a joke here about how unreadable doctor writing is.

Same in Italy.
Quote:

I thought the commenting was ok but it is in German. There is documentation in the vbcc manual for writing a backend and it appears to be much simpler than for some other compilers.

Yes, that's a nice part.

VAsm has something, but not at the same quality / coverage. Besides the main core for parsing the asm code, backends are usually very different. Basically, they are on their own. Which might be acceptable, since architectures might be very different (NEx64T will be quite different from x86/x64, because the opcode formats are totally different).
Quote:

There is a test suite and support code available for developers.

I have found nothing on the source code which I've download: is there something extra, which should be requested to the authors?
Quote:

Some of the support code is copyrighted so it is not available to everyone but it is available for developers that need it.

OK. Same for the test suite?
Quote:

That's what I worked on so it isn't too difficult to get. E-mail Frank Wille if you are interested. He is extremely helpful if you have questions and is the main person I dealt with. He is practically a support team himself which is a game changer for development efforts.

Got it. However one big thing that he should do is putting all sources on a distributed repo (Git-based. For the good and the bad, Git is The tool nowadays. However I don't like GitHub: I prefer some solution which is Gerrit-based, which has a phenomenal code reviews support).

This will help A LOT managing the project (he still has full controls over the changes!) and enabling external developers to support if they are willing to contribute.

As you said, the project is tiny: it's for a niche. And only a bunch of people are working on it.

However a small C compiler / development toolchain (assemblers, linker) has still a value, compared to the big monsters which are LLVM and GCC.

P.S. Not time to read again: I've to go work.

Hans Quote:

I looked into that, but it's not a workable solution. Here's a simple situation where it fails: a program writes data to a big-endian page, and copies it to a little-endian page. The memory copy routine has no idea of the data it's copied, and therefore cannot do any conversion. So, big-endian data ends up in a "little-endian page." It doesn't matter if the memory copy is done via DMA or CPU. Bulk data copies are common in graphics.

My instinct is that a CPU memory copy from a page with a different MMU marked endianness would be performed correctly with a swizzle. I expect the CPU will load the data of a certain datatype size and on store swizzle the data according to that datatype size which is now a consistent size (the original data needed to be swizzled according to the datatype size of each store which may have varied). I believe this would be the same as a byte copy from source to destination with no knowledge of endianness. A DMA engine memory copy is likely to load a certain data size and store the same size as a plain copy while the GPU DMA engine has no concept of the CPU MMU pages without HSA. Some DMA engines can perform swizzle and even decompress data on copy though. The XBox One DMA engines have that feature.

http://www.redgamingtech.com/xbox-one-sdk-leak-part-3-move-engines-memory-bandwidth-performance-tech-tribunal/ Quote:

Move engine 1 Plain copy, swizzle/unswizzle (title exclusive use) Move engine 2 Plain copy, swizzle/unswizzle (title exclusive use) Move engine 3 Plain copy, swizzle/unswizzle, Lempel-Ziv (LZ) lossless encode/decode (title exclusive use) Move engine 4 Plain copy, swizzle/unswizzle, JPEG decode (title/system shared use)

Maybe other work is already designated to the GPU DMA engines, maybe you don't have access to their control or maybe they are too primitive to swizzle.

Testing would be needed and dealing with different endianess is a pain. The MMU pages could be useful even if only copies to and from pages with the same endianness were possible. Rather than needing to know the datatype of every variable sized memory store, only the endianess of the destination buffer needs to be known and the MMU page endianess checked whether it is compatible.

Hans Quote:

Know of any modern GPUs on PCIe cards that still have big-endian support? The Northern Islands (Radeon HD 69xx series) were the last Radeon cards to be fully bi-endian. I've said it before: my personal opinion is that we need to accept that little-endian "won," and make the switch to little-endian just like IBM has done.

It doesn't make any sense to switch to little endian PPC as 68k AmigaOS and AmigaOS 4 PPC compatibility would be greatly reduced, not all PPC hardware has as good of support for little endian and PPC is as dead as big endian. If would make sense to break compatibility and convert to little endian if porting AmigaOS 4 to x86-64, AArch64 or RISC-V and make whatever changes are necessary for at least 64 bit and SMP. AROS is already on x86-64 and MorphOS has a big head start to get there as well. Cheaper and/or higher performance hardware would help an NG Amiga but a little endian AmigaOS and CPU will increase the divide between 68k Amiga and NG Amiga.

@matthey

Quote:

My instinct is that a CPU memory copy from a page with a different MMU marked endianness would be performed correctly with a swizzle.

Nope. A memory copy has no idea if any block of memory is storing 8-bit, 16-bit, 32-bit, 64-bit data, or, a combination thereof. Hence, it cannot know how to correctly swap the endianness. The information needed to perform byte swapping simply isn't there.

To correctly perform endianness conversion you need to know the structure of the data involved.

Quote:

It doesn't make any sense to switch to little endian PPC as 68k AmigaOS and AmigaOS 4 PPC compatibility would be greatly reduced, not all PPC hardware has as good of support for little endian and PPC is as dead as big endian. If would make sense to break compatibility and convert to little endian if porting AmigaOS 4 to x86-64, AArch64 or RISC-V and make whatever changes are necessary for at least 64 bit and SMP. AROS is already on x86-64 and MorphOS has a big head start to get there as well. Cheaper and/or higher performance hardware would help an NG Amiga but a little endian AmigaOS and CPU will increase the divide between 68k Amiga and NG Amiga.

Moving to a new Instruction Set Architecture (ISA) is also needed for reasons that have been debated to death on these forums already. Either the NG Amiga moves forward, or it's irrelevant.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

I hate to have to say it, but NG is irrelevant. It can do nothing of any practical merit for which there's not already better and more mature free software alternatives. NG has only one use and that's to provide an improved but familiar user experience to Amiga hobbyists on more recent hardware.

Since that hardware is now largely as unobtainable as the original classic hardware, it's not exactly killing this one identifiable job it has.

As you say, it needs to move onto a different ISA. ARM is a screamingly obvious choice here.

_________________
Doing stupid things for fun...

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: Just by case (well, not really: I've some interest), yesterday I've spent a lot of time tinkering on VBCC, VLink and VAsm, generating cross-compilers/assemblers at least for 68k, Excellent. Can you compile A09 optimized for smallest size and also for fastest operation, then tell us the file sizes? Should be easy as it's only a single .c file.

Unfortunately it doesn't work:

D:\src\vbcc>vc +aos68k -speed -o a09_aos68k_speed.exe -vv a09.c
vc frontend for vbcc (c) in 1995-2020 by Volker Barthelmann
flags=1414 opt=1 len=1476
Argument 6:a09.c
File "a09.c"=2
add_name: "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm"
vbccm68k "a09.c" -o= "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" -speed -hunkdebug -amiga-softfloat  -O=1 -I"D:\src\vbcc"\targets\m68k-amigaos\include
vbcc V0.9i pre (c) in 1995-2022 by Volker Barthelmann
vbcc code-generator for m68k/ColdFire V1.15 (c) in 1995-2022 by Volker Barthelmann
>#include 
error 248 in line 344 of "a09.c": file 'malloc.h' not found
1 error found!
vbccm68k "a09.c" -o= "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" -speed -hunkdebug -amiga-softfloat  -O=1 -I"D:\src\vbcc"\targets\m68k-amigaos\include failed
free p->obj
"C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm"
free p

cdimauro Quote:

Maybe for 68k. I haven't checked thoroughly, but I don't recall peephole optimizers for VBCC and Vasm; anyway, it's not important now.

One of Volker's ideas was to reduce the complexity and size of the compiler backend by moving peephole optimizations into the assembler. Vasm performs peephole optimizations for vbcc.

cdimauro Quote:

I have found nothing on the source code which I've download: is there something extra, which should be requested to the authors? OK. Same for the test suite?

You can ask Frank. There are definitely test programs used before new releases of vbcc but I don't know the availability or copyright status of them. Some of my 68k FPU support code changes were flagged by the tests and after investigation found to be WinUAE double precision instead of extended precision FPU emulation. Other compiler test programs like the GCC ones should be available and usable too.

cdimauro Quote:

Got it. However one big thing that he should do is putting all sources on a distributed repo (Git-based. For the good and the bad, Git is The tool nowadays. However I don't like GitHub: I prefer some solution which is Gerrit-based, which has a phenomenal code reviews support). This will help A LOT managing the project (he still has full controls over the changes!) and enabling external developers to support if they are willing to contribute.

A Github for vbcc and vasm would be more professional. Vbcc updates can take weeks but releases are usually tested. Vasm minor updates are usually available within a day and aren't as well tested but are usually created for someone else to test. Their system is unusual but it has worked for a long time and many others have made contributions.

cdimauro Quote:

Unfortunately it doesn't work: D:\src\vbcc>vc +aos68k -speed -o a09_aos68k_speed.exe -vv a09.c vc frontend for vbcc (c) in 1995-2020 by Volker Barthelmann flags=1414 opt=1 len=1476 Argument 6:a09.c File "a09.c"=2 add_name: "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" vbccm68k "a09.c" -o= "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" -speed -hunkdebug -amiga-softfloat -O=1 -I"D:\src\vbcc"\targets\m68k-amigaos\include vbcc V0.9i pre (c) in 1995-2022 by Volker Barthelmann vbcc code-generator for m68k/ColdFire V1.15 (c) in 1995-2022 by Volker Barthelmann >#include error 248 in line 344 of "a09.c": file 'malloc.h' not found 1 error found! vbccm68k "a09.c" -o= "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" -speed -hunkdebug -amiga-softfloat -O=1 -I"D:\src\vbcc"\targets\m68k-amigaos\include failed free p->obj "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" free p First I had to change the config files, because the %%VBCC%% didn't resolve to the the correct path. I also had to change the / in \. However and even after those changes, I'm stuck on the above error message (I've checked fully checked the vbcc folder, but there's no such file). I stop here, because I've already spent too much time only to cross-compile A09 (but I assume that I have issues with any regular C application, if they need to allocate memory).

The malloc.h header file is old and non-standard. Most likely, they are just using it for malloc() which is now standard in stdlib.h. If stdlib.h is not already included then add it and remove malloc.h. It is possible something not in stdlib.h is needed in which case you will need to obtain malloc.h but there may be different versions of it. If you can't get it from bhabbott then try the POSIX library which Frank Wille maintains mostly for vbcc.

https://aminet.net/package/dev/c/vbcc_PosixLib

POSIX headers and standard C headers don't mix well so don't blindly copy them over the vbcc headers. It's best to take the ones you need and keep them with the source to be compiled.

One other note. Vbcc is strict about C compliance while GCC allows slop code without complaining. Most programmers don't like this at first but it will sometimes save big trouble later.

bhabbott Quote:

So it could make the Amiga look better!

cdimauro Quote:

It will, from what I've seen.

The 68k backend of vbcc needs improvement. It is closer to that of SAS/C than GCC 2.95.3. The vbcc frontend is more advanced than SAS/C, vasm is a better assembler than the one in SAS/C and the support code is better, especially for the 68060 and floating point. The backend is the most important part for common and important integer code generation though.

Last edited by matthey on 22-Nov-2023 at 10:47 PM.

Hans Quote:

Nope. A memory copy has no idea if any block of memory is storing 8-bit, 16-bit, 32-bit, 64-bit data, or, a combination thereof. Hence, it cannot know how to correctly swap the endianness. The information needed to perform byte swapping simply isn't there. To correctly perform endianness conversion you need to know the structure of the data involved.

I did some tests and you are correct. Only blocks of data of a fixed and known datatype size can be swizzled on copy with DMA or the GPU. Even a CPU copy has to know the offsets and datatypes to swizzle by datatype size as it copies (except for byte sized datatypes). A LE to LE and BE to BE mem copy is a normal mem copy but a messenger can't translate a black box between BE and LE.

Hans Quote:

Moving to a new Instruction Set Architecture (ISA) is also needed for reasons that have been debated to death on these forums already. Either the NG Amiga moves forward, or it's irrelevant.

Up scaling Amiga hardware has led to expensive hardware that moves farther from original hardware and the much larger retro and hobby 68k Amiga market. BE has been an Amiga constant and LE will break more software than GPU software. There are integrated GPUs that still have BE support because there are still active BE SoCs, especially for networking where BE is "network order" and LE suffers from similar problems as using a LE GPU. Broadcom has active BE MIPS based SoCs like the BCM7346. The RPi supports BE and BE OSs including the GPU. The default RPi framebuffer even resembles a BE mode more than LE mode.

https://forums.raspberrypi.com/viewtopic.php?t=332161 Quote:

With most versions of the RPi firmware the framebuffer in 32-bit modes defaults to ABGR, which is backwards from most framebuffers which implement ARGB format. It is almost an endian swap (almost, as the alpha byte is still at the same place). As the conversion from the much more common ARGB to the RPi framebuffer is simpler for Big Endian data (just a rotate right by 24) than it is for Little Endian data (where you have to either swap the byte 0 with byte 2 or do a REV operation (byteswap on ARM) followed by a rotate right by 24).

The RPi GPU is old and primitive but Imagination Technologies owned MIPS which is BE until 2017 and is likely still supporting BE customers. They have GPUs advanced enough for the Apple iPhone.



A BE CPU and GPU with HSA! Memory copying problems between the CPU and GPU are greatly reduced with HSA. Transfers are much faster and shared memory can be cached. An integrated GPU can have just as much parallelism as a gfx card but it is more useful because there is less latency to access it. Imagination Technologies has advanced enough GPUs to support ray tracing which it currently claims to be using significantly less power than competitors. With the Amiga's history of ray tracing, it would be good for marketing an Amiga.

@cdimauro

Quote:

cdimauro wrote: Unfortunately it doesn't work: D:\src\vbcc>vc +aos68k -speed -o a09_aos68k_speed.exe -vv a09.c vc frontend for vbcc (c) in 1995-2020 by Volker Barthelmann flags=1414 opt=1 len=1476 Argument 6:a09.c File "a09.c"=2 add_name: "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" vbccm68k "a09.c" -o= "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" -speed -hunkdebug -amiga-softfloat -O=1 -I"D:\src\vbcc"\targets\m68k-amigaos\include vbcc V0.9i pre (c) in 1995-2022 by Volker Barthelmann vbcc code-generator for m68k/ColdFire V1.15 (c) in 1995-2022 by Volker Barthelmann >#include error 248 in line 344 of "a09.c": file 'malloc.h' not found 1 error found!

Oh sorry, I forgot that I had modified the code slightly - I commented out line 344.

Quote:

ATmega1284@25Mhz is a lot! You don't know what I was able to achieve with a crappy LilyPad Arduino USB board @ 8Mhz with 28kB Flash + 2.5kB RAM and without even touching the assembly (I've only used C and namespaces from C++).

Yeah, I overclocked it by 5MHz.

Reason being that in slightly over 1us it needs to :-
Detect start of the character ROM read cycle, read the ROM address lines from 2 input ports, create an address in RAM for the current character line, read the RAM and output the data on the ROM data lines,
and:-
Detect host CPU write to the control port, read command or data from the data bus, execute the command (select character, poke bitmap data into RAM, select page etc.). This has to work perfectly all the time or the screen will be corrupted.

AVR is a RISC architecture that is great for bare metal projects like this. It executes most instructions in 1 clock cycle and is totally deterministic (no caching or internal buses to synchronize etc.). A 68000 would probably need to run at over 100 MHz to do the same job. Of course 68k is much better for things that need more RAM etc. Horses for courses...

@matthey

PowerPC would be okay if it delivers a similar solution and price as PRi 4B.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

PowerPC would be okay if it delivers a similar solution and price as PRi 4B.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@Karlos

Quote:

I hate to have to say it, but NG is irrelevant. It can do nothing of any practical merit for which there's not already better and more mature free software alternatives. NG has only one use and that's to provide an improved but familiar user experience to Amiga hobbyists on more recent hardware.

Well, it's as irrelevant as the Amiga was early on in the 2,000s. The original Amiga is even more irrelevant despite what expensive souped up cards you buy it. By the late 90's the Amiga had fell behind compared to PC software and even DOS programs was givng it pressure. And now it's even worse with free software as you point out. The only relevance it has is to the Amiga market. Or the AmigaOne market I suppose.

@Hans

Quote:

Nope. A memory copy has no idea if any block of memory is storing 8-bit, 16-bit, 32-bit, 64-bit data, or, a combination thereof. Hence, it cannot know how to correctly swap the endianness. The information needed to perform byte swapping simply isn't there.

For a generic block of memory, x86 copying a block in reverse and ppc copying forward will end up exactly alike. Since x86 will reverse it in and reverse it out, while ppc will load it forward then store it forward, either result is the same. The crux here is specific scalars in reverse order.

The OS4 SDK uses GCC. Could GCC endian support help in this regard? That would put a dependency on GCC and break any portability, but since most modern code (and hardware) depends on little endian and thus is not portable, it already has a dependency.

https://gcc.gnu.org/onlinedocs/gcc/Structure-Layout-Pragmas.html
https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Common-Type-Attributes.html

@K-L

to me it is still a logic step from ppc-boards for classics to ppc motherboards.. it is not easy but it works.. hopefully it will get a change in the future.. in the meanwhile i support it while it goes further.. the link with linux is useful.. there is a way out.. we will see.. grtz,dirk

_________________
A1G3-SE + OS4.1 u1 iso (x2)

@amigang

yes, that was my thought also.. as long as linux can go to space with ppc etc.. then os4 can follow if it gets a change.. btw. today the uk and others are aiming for space, so why not.. grtz,dirk

_________________
A1G3-SE + OS4.1 u1 iso (x2)

@matthey

Quote:

matthey wrote: cdimauro Quote: Maybe for 68k. I haven't checked thoroughly, but I don't recall peephole optimizers for VBCC and Vasm; anyway, it's not important now. One of Volker's ideas was to reduce the complexity and size of the compiler backend by moving peephole optimizations into the assembler. Vasm performs peephole optimizations for vbcc.

I see, but I don't think that this is the best approach for this.

I had the same problem when I've forked and implemented my CPython version (WPython).
CPython has a peephole optimizer which works the same way: on the generated bytecode (it's a wordcode on WPython). However the range of possible optimizations was/is quite limited.
For this reason, on the next WPython version (1.1) I've completely moved the peephole optimizer from the bytecode/wordcode stage to the AST stage (once I've blocks of "instructions": a high-level representation of the parsed statements). This enabled more optimizations and, more important, it simplified a lot their implementation (especially when dealing with jumps: it's a nightmare with the bytecode/wordcode).

Anyway, that's not really important now. First the compiler should improve the support for the mainstream architectures, otherwise it'll be relegated to its current niche.
Quote:

cdimauro Quote: I have found nothing on the source code which I've download: is there something extra, which should be requested to the authors? OK. Same for the test suite? You can ask Frank. There are definitely test programs used before new releases of vbcc but I don't know the availability or copyright status of them. Some of my 68k FPU support code changes were flagged by the tests and after investigation found to be WinUAE double precision instead of extended precision FPU emulation. Other compiler test programs like the GCC ones should be available and usable too.

Looks good (and expected, frankly speaking).

I'll ask him if I finally decide to give a chance to VBCC as well.
Quote:

cdimauro Quote: Unfortunately it doesn't work: D:\src\vbcc>vc +aos68k -speed -o a09_aos68k_speed.exe -vv a09.c vc frontend for vbcc (c) in 1995-2020 by Volker Barthelmann flags=1414 opt=1 len=1476 Argument 6:a09.c File "a09.c"=2 add_name: "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" vbccm68k "a09.c" -o= "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" -speed -hunkdebug -amiga-softfloat -O=1 -I"D:\src\vbcc"\targets\m68k-amigaos\include vbcc V0.9i pre (c) in 1995-2022 by Volker Barthelmann vbcc code-generator for m68k/ColdFire V1.15 (c) in 1995-2022 by Volker Barthelmann >#include error 248 in line 344 of "a09.c": file 'malloc.h' not found 1 error found! vbccm68k "a09.c" -o= "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" -speed -hunkdebug -amiga-softfloat -O=1 -I"D:\src\vbcc"\targets\m68k-amigaos\include failed free p->obj "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" free p First I had to change the config files, because the %%VBCC%% didn't resolve to the the correct path. I also had to change the / in \. However and even after those changes, I'm stuck on the above error message (I've checked fully checked the vbcc folder, but there's no such file). I stop here, because I've already spent too much time only to cross-compile A09 (but I assume that I have issues with any regular C application, if they need to allocate memory). The malloc.h header file is old and non-standard. Most likely, they are just using it for malloc() which is now standard in stdlib.h. If stdlib.h is not already included then add it and remove malloc.h. It is possible something not in stdlib.h is needed in which case you will need to obtain malloc.h but there may be different versions of it. If you can't get it from bhabbott then try the POSIX library which Frank Wille maintains mostly for vbcc. https://aminet.net/package/dev/c/vbcc_PosixLib POSIX headers and standard C headers don't mix well so don't blindly copy them over the vbcc headers. It's best to take the ones you need and keep them with the source to be compiled.

OK, thanks.
Quote:

One other note. Vbcc is strict about C compliance while GCC allows slop code without complaining. Most programmers don't like this at first but it will sometimes save big trouble later.

Then I like it.

I'm very strict on coding (I've no problems on giving -1 reviewing patches which have even an extra white space).
Quote:

bhabbott Quote: So it could make the Amiga look better! cdimauro Quote: It will, from what I've seen. The 68k backend of vbcc needs improvement. It is closer to that of SAS/C than GCC 2.95.3. The vbcc frontend is more advanced than SAS/C, vasm is a better assembler than the one in SAS/C and the support code is better, especially for the 68060 and floating point. The backend is the most important part for common and important integer code generation though.

What's missing to the backend which SAS/C gives?


@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: Unfortunately it doesn't work: D:\src\vbcc>vc +aos68k -speed -o a09_aos68k_speed.exe -vv a09.c vc frontend for vbcc (c) in 1995-2020 by Volker Barthelmann flags=1414 opt=1 len=1476 Argument 6:a09.c File "a09.c"=2 add_name: "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" vbccm68k "a09.c" -o= "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" -speed -hunkdebug -amiga-softfloat -O=1 -I"D:\src\vbcc"\targets\m68k-amigaos\include vbcc V0.9i pre (c) in 1995-2022 by Volker Barthelmann vbcc code-generator for m68k/ColdFire V1.15 (c) in 1995-2022 by Volker Barthelmann >#include error 248 in line 344 of "a09.c": file 'malloc.h' not found 1 error found! Oh sorry, I forgot that I had modified the code slightly - I commented out line 344.

I've tried it but it still raises a couple of errors:

D:\src\vbcc>vc +aos68k -speed -o a09_aos68k_speed.exe -vv a09.c
vc frontend for vbcc (c) in 1995-2020 by Volker Barthelmann
flags=1414 opt=1 len=1476
Argument 6:a09.c
File "a09.c"=2
add_name: "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm"
vbccm68k "a09.c" -o= "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" -speed -hunkdebug -amiga-softfloat  -O=1 -I"D:\src\vbcc"\targets\m68k-amigaos\include
vbcc V0.9i pre (c) in 1995-2022 by Volker Barthelmann
vbcc code-generator for m68k/ColdFire V1.15 (c) in 1995-2022 by Volker Barthelmann
>  fnms[nfnidx] = strdup(name);
warning 161 in line 6235 of "a09.c": implicit declaration of function 
>  fnms[nfnidx] = strdup(name);
error 39 in line 6235 of "a09.c": invalid types for assignment
>  fnms[nfnidx] = strdup(name);
error 39 in line 6302 of "a09.c": invalid types for assignment
>  unlink(objname);
warning 161 in line 8561 of "a09.c": implicit declaration of function 
2 errors found!
vbccm68k "a09.c" -o= "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" -speed -hunkdebug -amiga-softfloat  -O=1 -I"D:\src\vbcc"\targets\m68k-amigaos\include failed
free p->obj
"C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm"
free p

Quote: ATmega1284@25Mhz is a lot! You don't know what I was able to achieve with a crappy LilyPad Arduino USB board @ 8Mhz with 28kB Flash + 2.5kB RAM and without even touching the assembly (I've only used C and namespaces from C++). Yeah, I overclocked it by 5MHz. Reason being that in slightly over 1us it needs to :- Detect start of the character ROM read cycle, read the ROM address lines from 2 input ports, create an address in RAM for the current character line, read the RAM and output the data on the ROM data lines, and:- Detect host CPU write to the control port, read command or data from the data bus, execute the command (select character, poke bitmap data into RAM, select page etc.). This has to work perfectly all the time or the screen will be corrupted. AVR is a RISC architecture that is great for bare metal projects like this. It executes most instructions in 1 clock cycle and is totally deterministic (no caching or internal buses to synchronize etc.). A 68000 would probably need to run at over 100 MHz to do the same job. Of course 68k is much better for things that need more RAM etc. Horses for courses...

@Hypex

Quote:

Hypex wrote: @Karlos Well, it's as irrelevant as the Amiga was early on in the 2,000s. The original Amiga is even more irrelevant despite what expensive souped up cards you buy it

So, let's be honest about it: Original Amiga may be a "has been", but by comparison NG, all flavours combined is a "was nobody".

NG has never achieved the relevance that the original had. The NG userbase is likely a strict subset: I'd be entirely willing to believe that there are literally zero NG users that weren't previous Amiga users. In reality there may have been one or two oddball fans of esoteric systems but I'd be willing to bet they all used AROS or MOS because nobody is stupid enough to drop the cost of a "new" OS4 machine on something they are going to use for 10 mins to satisfy their curiosity.

Right now, today, the classic Amiga scene is far more "relevant", by just about any sensible metric you can define than the NG one.

_________________
Doing stupid things for fun...

@matthey

Quote:

Broadcom has active BE MIPS based SoCs like the BCM7346. The RPi supports BE and BE OSs including the GPU. The default RPi framebuffer even resembles a BE mode more than LE mode.

Quote:

With most versions of the RPi firmware the framebuffer in 32-bit modes defaults to ABGR, which is backwards from most framebuffers which implement ARGB format. It is almost an endian swap (almost, as the alpha byte is still at the same place). As the conversion from the much more common ARGB to the RPi framebuffer is simpler for Big Endian data (just a rotate right by 24) than it is for Little Endian data (where you have to either swap the byte 0 with byte 2 or do a REV operation (byteswap on ARM) followed by a rotate right by 24).

ABGR is not directly supported, BGRA most is kind supported with reverse load and store assembler options, in EUAE there is decent assembler snippet that handles that conversion at near copy speed.

ABGR mode is a bit more trouble some as its not directly supported, no special instruction can do the conversion in one operation that I know of, the only why can accelerate it, is by handling more one pixel in one operation, that be 64bit operation, unless you can invoice AltiVec like instruction.

in any case you need load 64bit value, this allows you mask two red channels. Shift it.
then you load another 64bit value, mask it, and shift it, and then another you need to mask and shift again, then you need to or the result, and store it.

so that 4 times you need to load a register, (perhaps you can copy registers, to avoid the memory transfer), then you need 4 and operation, 4 shift operation, (you do not know what alpha is, so you can’t just discard it), and then you need 4 or operations, and one store.

You are looking at 4+4+4+4+1 = 33 operations to do a simple conversion, horror. You better not convert something that does not need conversion.

it helps if can can discard the alpha, so now you have 3+3+3+4+1=14, by my count.

You do reverse load on GR, that can help perhaps, but working in 16bit often a bad idea.

Blue (l+sr+and+or)
Red+Green (rl+sl+or)
Alpha (or)
store

9 operations, for one pixel,

(but you can't do double resvere load in 64bit, so that trick does not work.)

you do Blue and Alpha in 64bit, then you need to do Red+Green twice.

5+(3*2)+1= 12 operations by my count, at best. so almost the same as 14..

I know some AltiVec has some mask and shift so they can perhaps reduce the operations, now suck at writing AltiVec so I don’t do it, and I have yet tried asking ChatGPT.
Personally, I like 16 bit conversion because with 64bit, I can do 4 pixels, with 33 operations, theoretically, that at least is not as horrible.

Perhaps why we are seeing so good benchmarks at exactly 16bit.

Last edited by NutsAboutAmiga on 23-Nov-2023 at 08:56 PM.
Last edited by NutsAboutAmiga on 23-Nov-2023 at 08:53 PM.
Last edited by NutsAboutAmiga on 23-Nov-2023 at 08:49 PM.
Last edited by NutsAboutAmiga on 23-Nov-2023 at 08:36 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Before you start worrying about that, consider how memory bound any block conversion is. Your loop, if properly written ought to be sat in the instruction cache and all your bus bandwidth is available for data. The individual cycle efficiency of the per element loop may be less important then you think if the memory bus ends up being the limit anyway.

_________________
Doing stupid things for fun...

@Karlos

In any case its always better to stick to format given, and never convert between the formats if you can. And from previous experiments, never good to generalize on a macro level because, complexity should always be on top down. Not from the bottom up. That means many large specialized routines for etch mode, not one rutine using a generalized pixel plotter.

It can be that with templets in C++, it be easier to do that now. without making lot duplications in code, and potential for code not full updated at all places, kind of bugs.

Your right memory bandwidth can be more important than conversation, that was a hard lesson in EUAE. We also covered that in lot topic about C2P in AGA.

Last edited by NutsAboutAmiga on 23-Nov-2023 at 09:08 PM.
Last edited by NutsAboutAmiga on 23-Nov-2023 at 09:07 PM.
Last edited by NutsAboutAmiga on 23-Nov-2023 at 09:05 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS