@cdimauro

Quote:

cdimauro wrote: > 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! Could you please share your source?

The source is just what's in that Aminet archive, but with line 344 commented out (I checked it with a diff program so I am 100% sure that I didn't make any other changes).

cdimauro Quote:

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.

The peephole optimizations that an assembler can safely perform are limited especially on the 68k due to CC flags. I don't see any problem with letting the assembler do the optimization it can but the backend needs to do the optimizations which the assembler can't. This is something that Volker has been slow to adjust to. For example, vbcc would emit "movem.l d0,-(sp)" which should be changed to "move.l d0,-(sp)" but vasm can't do it because the latter changes the CC flags. The backend needs special cases when the register list has 1 or 2 registers.

cdimauro Quote:

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

SAS/C is not bad but showing its age. The frontend is simple and the backend is basic. The code generation quality is consistently mediocre. The code generated by vbcc can be very good in places and bad in others. The main problem is the minimalist 68k backend that Volker can't justify spending a lot of time on without more competitive 68k hardware available. I doubt he touches 68k hardware for development if he still has any. Frank has and uses 68k Amiga hardware. He has programmed and ported several Amiga games.

cdimauro Quote:

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

That's the kind of strictness I was talking about. Vbcc teaches some good C lessons. Don't think these errors are bugs in vbcc. Volker knows his C.

NutsAboutAmiga Quote:

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 in little endian would be RGBA in big endian which was a Silicon Graphics format.

https://en.wikipedia.org/wiki/RGBA_color_model

From RGBA, a ROR.L #8,Dn is all that is needed to convert to ARGB. The RPi GPU is old. Big endian and silicon graphics old?

@Dirk-B

Quote:

Dirk-B wrote: @K-L to me it is still a logic step from ppc-boards for classics to ppc motherboards...

In the late '90s and early 2000s it was a logical step.

Every year since 2007 it has been less and less logical, to the point where in 2023 it is illogical, unreasonable, and I'd go as far to say irresponsible.

_________________
All the way, with 68k

@Hypex

Quote:

Hypex wrote: @Karlos [in the 2000s] The original Amiga is even more irrelevant despite what expensive souped up cards you buy it...

I like the phrasing here: We didn't buy cards for ourselves, we bought if for our beloved Amigas.

Here you go Miggie, a faster CPU and a nice big tower case in which to stretch out.
Here you go Miggie, a PCI daughterboard so you can have PCI cards like Voodoo 3D graphics cards, Ethernet cards, 16-bit sound cards.
Do you like the new cards I bought for you, Miggie?

In my personal journey with my Franken-miggie, Amiga relevance took a noticeable drop starting in late 1997. I spent almost an equal amount of time using MacOS 8 in ShapeShifter.

The last couple of years before her motherboard fried (2000 - 2001), I was mostly running Debian on BlizzardPPC with Bvision.

Come 2002, most of the creative work had moved to MacOS 9.x on a PowerBook G4 Ti, and gaming had moved to an Athlon rig running Windows XP.
What used to be the domain of a single personal computing platform had been bifurcated into two distinct platforms. Neither of which were doing things quite right. Not even to this very day.

_________________
All the way, with 68k

@Karlos

Quote:

... it needs to move onto a different ISA. ARM is a screamingly obvious choice here.

My idea exactly and when at it, RISC-V becomes more and more of an additional option.

My €0,02 anyway...

Have a nice weekend!

OldFart

_________________
More then three levels of indigestion and you're scroomed!

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: > 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! Could you please share your source? The source is just what's in that Aminet archive, but with line 344 commented out (I checked it with a diff program so I am 100% sure that I didn't make any other changes).

Then I can do nothing else (I've no time now to check what's the type inconsistency and fix it).

However if you want to give a try, you can easily do it: just download the multi-platform VBCC archive which contains everything already setup, set some ENVAR, and try with the command which I've used.


@matthey

Quote:

matthey wrote: cdimauro Quote: 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. The peephole optimizations that an assembler can safely perform are limited especially on the 68k due to CC flags. I don't see any problem with letting the assembler do the optimization it can but the backend needs to do the optimizations which the assembler can't. This is something that Volker has been slow to adjust to. For example, vbcc would emit "movem.l d0,-(sp)" which should be changed to "move.l d0,-(sp)" but vasm can't do it because the latter changes the CC flags. The backend needs special cases when the register list has 1 or 2 registers.

Yes, that's what I've meant before, because I've immediately seen it when I've compiled (and just dumped to assembly) the Fibonacci example:

	machine	68030
	opt o+,ol+,op+,oc+,ot+,oj+,ob+,om+
	section	"CODE",code
	public	@fib
	cnop	0,4
@fib
	movem.l	l6,-(a7)
	move.l	d0,d3
	moveq	#1,d0
	cmp.l	d3,d0
	blt	l4
	moveq	#1,d0
	bra	l5
l4
	move.l	d3,d0
	subq.l	#2,d0
	jsr	@fib
	move.l	d0,d2
	move.l	d3,d0
	subq.l	#1,d0
	jsr	@fib
	add.l	d2,d0
l5
l6	reg	d2/d3
	movem.l	(a7)+,d2/d3
l8	equ	8
	rts
	machine	68030
	opt o+,ol+,op+,oc+,ot+,oj+,ob+,om+
	public	@main
	cnop	0,4
@main
	movem.l	l11,-(a7)
	moveq	#3,d0
	jsr	@fib
l11	reg
l13	equ	0
	rts

@Karlos

Quote:

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

Ten years ago I would have called this a false path, because all ARM boards I knew where over-priced and under-powered evaluation systems, custom build hardware tends to be far worse ( X1000, X5000, ... ) but now there is a Raspberry and some other companies making similar hardware.

For some hardcore Amigans this wouldn't be enough, because the performance is below a desktop PC but it could be a way to go for with an open Source OS, something that could be ported fast to other platforms, something like AROS.

But the audience here don't like AROS, the Amiga fans want it to be Amiga and this means Hyperion and Hyperion is going nowhere.

Last edited by OneTimer1 on 25-Nov-2023 at 12:34 AM.
Last edited by OneTimer1 on 24-Nov-2023 at 10:09 PM.

@matthey

Quote:

From RGBA, a ROR.L #8,Dn is all that is needed to convert to ARGB. The RPi GPU is old. Big endian and silicon graphics old?

Yeh that will work, there is similar shift opcode for PowerPC as well.
Also as did check before writing last post, there is instructions that does masking and shifting in one operation as well. That cuts down operations needed as well.
I write most of stuff in C/C++ , so some thing can perhaps get optimized more, if know the instruction sets better. The C compiler does a pretty good job most of time.

But most typical issue, is that game was written for ARGB, and but you need reverse endianness for graphics, so you need BGRA, now that probably huge issue as it can be reversed at load time, now that work pretty well, unless the games modify one of channels, during game play. I’m sure biggest issue is not colors but floats and doubles for vector graphics, technical is the same routines, you don’t see how it can be avoid, unless there is secondary buffer to only push the changes.

Last edited by NutsAboutAmiga on 25-Nov-2023 at 03:44 AM.
Last edited by NutsAboutAmiga on 25-Nov-2023 at 03:39 AM.

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

@cdimauro

Quote:

cdimauro wrote: Then I can do nothing else (I've no time now to check what's the type inconsistency and fix it). However if you want to give a try, you can easily do it: just download the multi-platform VBCC archive which contains everything already setup, set some ENVAR, and try with the command which I've used.

Very interesting!

I installed vbcc without much drama on my Vampired A600 (just bought a second-hand 32" LED TV and it's working brilliantly in 16:9 at 1280x800).

Turns out strdup() is a XENIX or POSIX function, not ANSI C. It's easy enough to 'duplicate' with the following code:-

char *strdup (const char *s) {
    char *d = malloc (strlen (s) + 1);   // Allocate memory
    if (d != NULL) strcpy (d,s);         // Copy string if okay
    return d;                            // Return new memory
}

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: Then I can do nothing else (I've no time now to check what's the type inconsistency and fix it). However if you want to give a try, you can easily do it: just download the multi-platform VBCC archive which contains everything already setup, set some ENVAR, and try with the command which I've used. Very interesting! I installed vbcc without much drama on my Vampired A600 (just bought a second-hand 32" LED TV and it's working brilliantly in 16:9 at 1280x800). Turns out strdup() is a XENIX or POSIX function, not ANSI C. It's easy enough to 'duplicate' with the following code:- char *strdup (const char *s) { char *d = malloc (strlen (s) + 1); // Allocate memory if (d != NULL) strcpy (d,s); // Copy string if okay return d; // Return new memory }

Thanks! It worked now.
Quote:

unlink() is another non-standard function used in UNIX that 'removes' (deletes?) a named file. In this case it's used to 'remove' the output file if an error occurs. Not critical for our purposes so I just commented it out. Shouldn't make much difference to the file size, I'm guessing less than 100 bytes smaller than it should be.

Just replace unlink with remove (which is on the stdlib).
Quote:

vbcc isn't fast, but it's OK on the Vampire. On my system it took 58 seconds to compile A09.c.

On my old PC (Intel's 6700K) it takes around one second.
Quote:

Using your command line with option -speed, the executable file size was 91904 bytes. I changed -speed to -size, and the output file size was... 91904 bytes! Compared to the original compiled with GCC it's 11% smaller - not bad! But only 4% smaller than SASC. Next question is would vbcc produce smaller ppc code. Unfortunately I don't have the setup to find out, or any way of testing the code produced. So at this point the 'best compiler' result is 91904 vs 191424 = 1:2.1 in favor of 68k vs ppc code size.

I report my results (which are very strange compared to yours):

vc +aos68k -speed -o a09_aos68k_speed.exe -vv a09.c
vc +aos68k -size -o a09_aos68k_size.exe -vv a09.c
EXE: 753560 bytes
CODE(acrx4):           58133 bytes
DATA(adrw4):          675864 bytes
BSS(aurw4):           275912 bytes

vc +aosppc -speed -o a09_aosppc_speed.exe -vv a09.c
EXE: 1145576 bytes
.text(acrx16):         72848 bytes
.rodata(adr4):         11693 bytes
.data(adrw4):         677976 bytes

vc +aosppc -size -o a09_aosppc_size.exe -vv a09.c
EXE: 1142908 bytes
.text(acrx4):          72100 bytes
.rodata(adr4):          9784 bytes
.data(adrw4):         677956 bytes

vc +i386-dosc -speed -o a09_i386-dosc_speed.exe -vv a09.c
EXE: not generated (link issues)
.text(acrx4):          60265 bytes
.data(adrw4):         675864 bytes
.bss(aurw1):              12 bytes

vc +i386-dosc -size -o a09_i386-dosc_size.exe -vv a09.c
EXE: not generated (link issues)
.text(acrx4):          60261 bytes
.data(adrw4):         675864 bytes
.bss(aurw1):              12 bytes

D:\src\vbcc>vc +i386-dosc -speed -o a09_i386-dosc_speed.exe -vv a09.c
vc frontend for vbcc (c) in 1995-2020 by Volker Barthelmann
flags=1414 opt=1 len=1405
Argument 6:a09.c
File "a09.c"=2
add_name: "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm"
vbcci386 -I"D:\src\vbcc"\targets\i386-dos\include "a09.c" -o= "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" -speed -safe-fp -elf  -O=1
vbcc V0.9i pre (c) in 1995-2022 by Volker Barthelmann
vbcc code-generator for i386 V0.7a (c) in 1996-2006 by Volker Barthelmann
add_name: "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.o"
add_name: "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.o"
vasmx86_std -Felf -nowarn=62 "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm" -o "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.o"
vasm 1.9a (c) in 2002-2022 Volker Barthelmann
vasm x86 cpu backend 0.7a (c) 2005-2006,2011,2015-2019 Frank Wille
vasm std syntax module 5.3b (c) 2002-2021 Volker Barthelmann
vasm ELF output module 2.7a (c) 2002-2016,2020,2022 Frank Wille

.text(acrx4):          60265 bytes
.data(adrw4):         675864 bytes
.bss(aurw1):              12 bytes
linklen=273
vlink -v -Cvbccelf -brawbin1 -T"D:\src\vbcc"\targets\i386-dos\vlink.cmd -L"D:\src\vbcc"\targets\i386-dos\lib
"D:\src\vbcc"\targets\i386-dos\lib\startup.o "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.o" 
-lvc -o a09_i386-dosc_speed.exe -e __cstart
vlink V0.17a (c)1997-2022 by Frank Wille
build date: Apr 28 2022, 16:42:21

Standard library path:
Default target: rawbin1
Supported targets: amigahunk amigaehf ataritos xfile os9-6809 o65-02 o65-816 elf32ppcbe elf32powerup elf32morphos
elf32amigaos elf32m68k elf32i386 elf32aros elf32armle elf32jag elf64x86
aoutnull aoutsun010 aoutsun020 aoutbsd68k aoutbsd68k4k aoutmint aoutbsdi386 aoutpc386
aoutjaguar vobj-le vobj-be rawbin1 rawbin2 amsdos applebin ataricom bbc bbc2
cbmprg cbmreu cocoml dragonbin oricmc jagsrv sinclairql srec19 srec28 srec37 ihex oilhex rawseg
del "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm"
del "C:\Users\Cesare\AppData\Local\Temp\vbcc068c.o"
free p->obj
"C:\Users\Cesare\AppData\Local\Temp\vbcc068c.o"
free p
free p->obj
"C:\Users\Cesare\AppData\Local\Temp\vbcc068c.asm"
free p
free p->obj
"C:\Users\Cesare\AppData\Local\Temp\vbcc068c.o"
free p

Last edited by cdimauro on 25-Nov-2023 at 01:12 PM.

@bhabbott

I appreciate it's not the point, but the strdup() code might want to check the source isn't null before continuing.

_________________
Doing stupid things for fun...

@Karlos: but at least it's not bugged.

@bhabbott

its maybe smaller, but strcpy is possibly not inlined, that means extra branches,
small size != speed.

Unless we are talking about compile speed , not executable speed.

Last edited by NutsAboutAmiga on 25-Nov-2023 at 12:05 PM.
Last edited by NutsAboutAmiga on 25-Nov-2023 at 12:03 PM.

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

@cdimauro

Quote:

cdimauro wrote: EXE: 753560 bytes CODE(acrx4): 58133 bytes DATA(adrw4): 675864 bytes BSS(aurw4): 275912 bytes vc +aosppc -speed -o a09_aosppc_speed.exe -vv a09.c EXE: 1145576 bytes .text(acrx16): 72848 bytes .rodata(adr4): 11693 bytes .data(adrw4): 677976 bytes

My compile of 68k -speed reported:-

Code: 53209
data: 20172
bss: 931268

The hunk sizes in the executable are:-

Code: 65360
data: 6
data: 20460
data: 12
data:16
bss: 931332

Looks like your compiler isn't handing BSS properly. A09 has a large amount of it, so this makes the file size increase dramatically.

@cdimauro

Quote:

cdimauro wrote: @Karlos: but at least it's not bugged.

Hum. I've some doubts now.

I was recalling that strlen() checked if the argument was a null pointer and giving back 0 as its length, but looking around I've found no confirmation about it.

On exact the contrary, the NetBSD implementation simply assumes that the pointer should not be null and immediately uses it.

So, I'm not sure anymore if the above strdup is bugged or not.


@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: EXE: 753560 bytes CODE(acrx4): 58133 bytes DATA(adrw4): 675864 bytes BSS(aurw4): 275912 bytes vc +aosppc -speed -o a09_aosppc_speed.exe -vv a09.c EXE: 1145576 bytes .text(acrx16): 72848 bytes .rodata(adr4): 11693 bytes .data(adrw4): 677976 bytes My compile of 68k -speed reported:- Code: 53209 data: 20172 bss: 931268 The hunk sizes in the executable are:- Code: 65360 data: 6 data: 20460 data: 12 data:16 bss: 931332 Looks like your compiler isn't handing BSS properly. A09 has a large amount of it, so this makes the file size increase dramatically.

Exactly, but that's one problem. The other one is that the compiler that I've used (well, it's the one from the VBCC page!) generated 5kB more code for the 68k compared to your.

So, there should be definitely something wrong (also for the i386, since the configuration doesn't include a stdlib / target by default. Contrary to the 68k and PowerPC targets).

@Karlos

Quote:

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".

Ha. Well NG was made in the shadow of the Amiga. It was intended to be made in the image of the Amiga but really lived in the shadow.

I recall sometime near the 2000's the Amiga still had a chance of a come back. This will be vague but at the time there was some Star Wars game on the PC. But then it was just left too long and they lost it. Not for the fault of the Amiga but it was screwed over again. However they really would have needed to get it up to scratch. Fix the Workbench so it wasn't so sloppy and make it more professional. Forget about planar and add pracital packed plxel modes as well as 16 bit audio and FFS add a midi port!

Quote:

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.

10 mins to satisfy their curiosity? No way. The AmigaOne cannot be better than sex!

NG and in my own case OS4 as NG only makes sense having been an exising Amiga user. It couldn't offer anyone else anything. An OS modeled around an antique multitasking design that is too rigid to be upgraded to 64 bit and SMP isn't useful for many people.

The fact is the AmigaOne/XE could never have the same effect as the Amiga. By the time it came out and it was the only Amiga-ish hardware that came out I recall, it was really too late for the Amiga. By at least 5 years. The gap between the Amiga and the One was just too large. You couldn't plug a Toaster into it. It had no Zorro slots. You couldn't even genlock it. It would have been too expensive even to include AGA on a PCI card and realisitically an 80's 16-bit chipset with a 32-bit hack because it's Amiga was not practical. And yeah, I was annoyed they abandoned the original AmigaOne design, that plugged into a real Amiga A1200. The best of both worlds and they ruined it! Sure, a stand alone machine is more practical, but this was meant as a bridge from the original Amiga. Well they burnt that bridge!

Quote:

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

What relevant to Amiga users? It's certainly not relevant to the rest of the world. And no, by extension, I don't include Amiga emulators with that. I find it pointless to compare with an emulator as it's an unnatural environment relying on the host for speed. Like, you don't buy AmigaOS 3.2 to run in an emulator, you buy it for the real thing. You can test it in an emulator but only running it in emulation seems pointless.

@cdimauro

Quote:

cdimauro wrote: I was recalling that strlen() checked if the argument was a null pointer and giving back 0 as its length, but looking around I've found no confirmation about it. On exact the contrary, the NetBSD implementation simply assumes that the pointer should not be null and immediately uses it. So, I'm not sure anymore if the above strdup is bugged or not.

These functions come from a time when programmers understood that great power came with great responsibility. If you wanted a language that protected you from yourself then you used BASIC (and accepted the massive performance loss).

In this case strdup() is taking the name of a file which has already been opened, so it must be valid. Why do another test inside it that just wastes time and memory?

One of the reasons people don't like strdup() is that it allocates memory when other string functions don't. This can lead to memory leaks when people forget to free the memory. It can also cause memory fragmentation, which is a big problem on the Amiga.

Why is strdup considered to be evil
Quote:

It's not strictly ANSI C, but rather POSIX. Consequently, some compilers (e.g. MSVC) discourage use (MSVC prefers _strdup), and technically the C standard could define its own strdup with different semantics since str is a reserved prefix. So, there are some potential portability concerns with its use. It hides its memory allocation. Most other str functions don't allocate memory, so users might be misled (as you say) into believing the returned string doesn't need to be freed.

But it's a pussycat compared to alloca()...

Why is the use of alloca() not considered good practice?
Quote:

Q: alloca() allocates memory on the stack rather than on the heap, as in the case of malloc(). So, when I return from the routine the memory is freed. So, actually this solves my problem of freeing up dynamically allocated memory. Freeing of memory allocated through malloc() is a major headache and if somehow missed leads to all sorts of memory problems. Why is the use of alloca() discouraged in spite of the above features? A: Not all compilers support alloca. Some compilers interpret the intended behaviour of alloca differently, so portability is not guaranteed even between compilers that support it. Some implementations are buggy.

cdimauro Quote:

Yes, that's what I've meant before, because I've immediately seen it when I've compiled (and just dumped to assembly) the Fibonacci example: machine 68030 opt o+,ol+,op+,oc+,ot+,oj+,ob+,om+ section "CODE",code public @fib cnop 0,4 @fib movem.l l6,-(a7) move.l d0,d3 moveq #1,d0 cmp.l d3,d0 blt l4 moveq #1,d0 bra l5 l4 move.l d3,d0 subq.l #2,d0 jsr @fib move.l d0,d2 move.l d3,d0 subq.l #1,d0 jsr @fib add.l d2,d0 l5 l6 reg d2/d3 movem.l (a7)+,d2/d3 l8 equ 8 rts machine 68030 opt o+,ol+,op+,oc+,ot+,oj+,ob+,om+ public @main cnop 0,4 @main movem.l l11,-(a7) moveq #3,d0 jsr @fib l11 reg l13 equ 0 rts This, added to what you've said, is a clear example that shows why the peephole optimizer should be moved to VBCC's backend. Another, even more important, example is embedding assembly code. This requires that the compiler does nothing: just report it as it is to the assembly. My expectation is that the assembler doesn't change it as well. However, how it could know that the assembled code was generated by the compiler or was just embedded? It can't, because it's missing this information which, on the other hand, was available to the compiler. In general, the compiler has much more metadata available which allows to take better decision when doing optimization, peephole ones include. Which, anyway, doesn't prevent to move some optimization the assembler's peephole.

Yes, the code you posted is a good example of what I'm talking about. Tthe use of JSR instead of BSR is another backend simplification but vasm likely peephole optimizes this where possible. The vasm peephole optimization of branches and displacements is a success for Volker's backend simplification strategy but failing to add backend optimizations where peephole optimizations by the assembler can't be performed sabotages this strategy. I had hope Volker would improve the 68k backend code generation quality when Individual Computers sponsored vbcc but, last I looked, most changes were bug fixes.

I considered writing a new 68k backend but this would take a long time, especially debugging, and there would be no guarantee Volker would replace the current one for the main vbcc distribution even if it was better (much like some 68k GCC backend efforts). I believe a 68k instruction scheduler could optimize MOVEM instructions into MOVE instructions as it must track CC flags. This would be an unusual use of an instruction scheduler but it does follow Volker's strategy of simplifying the backend and better dividing the workload which potentially reduces memory use and offers better performance with SMP. Other optimizations could be performed as well. When compiling for size, an instruction scheduler for the 68020 ISA could combine instructions to use double memory indirect addressing modes for the cases which improve code density. The backend generating instructions using these addressing modes is bad as it limits instruction scheduling opportunities but the instruction scheduler could fuse instructions after determining no other instruction can be scheduled between. This optimization would be mostly for ultra code density bragging rights but my point is that some optimizations may be better performed by the scheduler.

cdimauro Quote:

VBCC can be improved by taking those bad cases and taking a look at what SAS/C does.

GCC 2.95.3 is the compiler 68k backend integer code generation to look at. It is very good although the FPU and support code are not as good. Vbcc 68k code generation for the FPU already beats every 68k compiler I'm aware of even though there is further room for improvement. Integer code is far more important though. If the vbcc 68k backend or (a new 68k instruction scheduler) performed the peephole optimizations that vasm can't, there wouldn't be many cases where SAS/C generated better quality code, at least for the 68020+. SAS/C generated code tends to use small datatypes which more efficiently use registers while vbcc generated code often prefers to extend smaller datatypes to the register size which avoids partial registers stalls and is often better on the 68020+ and especially 68060. The ColdFire MVS and MVZ instructions (MOVSX/MOVZX in x86) would provide great benefit to the vbcc 68k backend. The 68k backend already supports ColdFire and I worked with Frank to add ColdFire peephole optimization to vasm as well so the support just needs to be turned on. It's too bad these instructions didn't make it into the 68060 as they would have significantly improved performance and code density.

cdimauro Quote:

Having a bug/features tracking tool helps, but I haven't seen it for VBCC.

I reported bugs to Frank which he tried to verify and determine where they come from. Frank is active on EAB and often answers vbcc and vasm related questions in the "Coders" section. I recalled the Mantis bug tracker being used somewhere but I couldn't find anything with a search. It's possible it is used internally.

NutsAboutAmiga Quote:

Yeh that will work, there is similar shift opcode for PowerPC as well. Also as did check before writing last post, there is instructions that does masking and shifting in one operation as well. That cuts down operations needed as well. I write most of stuff in C/C++ , so some thing can perhaps get optimized more, if know the instruction sets better. The C compiler does a pretty good job most of time. But most typical issue, is that game was written for ARGB, and but you need reverse endianness for graphics, so you need BGRA, now that probably huge issue as it can be reversed at load time, now that work pretty well, unless the games modify one of channels, during game play. I’m sure biggest issue is not colors but floats and doubles for vector graphics, technical is the same routines, you don’t see how it can be avoid, unless there is secondary buffer to only push the changes.

The RPi GPU supports 32 bit big endian gfx modes which are listed in the link I posted. It is odd that the default mode looks like a very old big endian mode but it is a very old GPU. It is not a high performance or flexible GPU design but it is low power and has scaled up in performance with higher clock speeds and more memory bandwidth. Simple old logic designs save power and just need silicon upgrades occasionally.

NutsAboutAmiga Quote:

its maybe smaller, but strcpy is possibly not inlined, that means extra branches, small size != speed. Unless we are talking about compile speed , not executable speed.

Vbcc uses assembler inlines by default for both the 68k and PPC where practical but they are practical more often on the 68k due to smaller code. The inlines are in the standard C header files if available. Some of the assembler inlines are smaller and some are larger compared to not using inlines. The inlines can be easily turned off but overall code size may increase. Last I looked, there was not enough sophistication to turn off assembler inlines which increase code size when compiling for size (-Os).

@Hypex

Quote:

Hypex wrote: @Karlos Like, you don't buy AmigaOS 3.2 to run in an emulator, you buy it for the real thing.

Yeah, screw those tens of thousands of AmigaForever and free UAE users on Windows, Linux, and Mac. Those infidels already have OS 3.9 and AROS 68k.
For many of them, their only Amiga experience is via emulation, but it's really their own failing for not maintaining their original Amiga(s) or not willing to put down what is on average couple months of salary on acquiring a Commodore classic.

OS 3.2 is clearly made for the Commodore Amiga OG 68k master race. Where we only very reluctantly accept AT (ESCOM) manufactured Amigas as part of the same gene pool.

_________________
All the way, with 68k

agami Quote:

Yeah, screw those tens of thousands of AmigaForever and free UAE users on Windows, Linux, and Mac. Those infidels already have OS 3.9 and AROS 68k. For many of them, their only Amiga experience is via emulation, but it's really their own failing for not maintaining their original Amiga(s) or not willing to put down what is on average couple months of salary on acquiring a Commodore classic.

The elites decided our destiny and need not declare. If the Amiga peasants have no more bread, let them eat cake. We would rather starve than eat your cake. We will eat pancakes until you have no more bread!

agami Quote:

OS 3.2 is clearly made for the Commodore Amiga OG 68k master race. Where we only very reluctantly accept AT (ESCOM) manufactured Amigas as part of the same gene pool.

AmigaOS 3.2 is sold by the same corrupt elites that steal our bread and offer us cake. We would rather starve than eat your cake. We will eat pancakes until you have no more bread!