Apollo Maggie 3D Chip - Preview Demo

[Gorf]

Originally Posted by meynaf

None of these are anything we'd want to do on our Amigas, in case you have not noticed.

we is?
You don't, I do ...

If your claims are true and 68k implementation would bring at least a 10x speedup, I would not only use it on my real hardware for fun, but also together with a 68k-emulation in production, because it still would be faster this way...

Which amounts to ?

You defined the unit molehill yourself.
(1 molehill = 1 CouchDB clone in handcrafted 68k assembler)

I didn't follow the project, but yes, maybe it was slow dev because of ASM.
But may I recall you the terrible truth ? It is x86 asm !

Where's the point in doing that ? We already have a lean-and-mean OS !

It has SMP multiprocessor support and memory protection.
Which brings us even back to the topic: Vampire/Apollo
According to Gunnar his 68080 has already hyper-threading and is SPM-ready ... only AmigaOS can not make use of it.

As you are lazy, you can understand I may be lazy as well.
Thus i'd prefer having someone implement in HLL something that's already done in handcrafted ASM

Concrete suggestions (in molehill size)?

Nah, frankly, do you really want to have all these on the Amiga ?

As for Ratatouille, Toby, Loki, ExCLI and Numerix: YES

Yes, 68k Macs as well.

But your framework does not exist on Atari or Mac ... so again we will never know...

It's not "secret", a few people got some version of it. It starts by just asking.

OK ... so only for the inner circle ...

How did Apple handle compatibility with 68k code when they switched to PPC already ?.

In the end by forcing people to recompile their software or abandon it.
Like they did then with PPC on x86 and now with 32-bit ARM and x86 and will do with x86_64 in a while.

Sorry, i've got enough "nice" things to do.
Why should i prove anything, anyhow ?.

to clear any doubts.

Like a player for some audio format, for example ?
You (or anyone) could attempt to beat my 030-optimized version of mpega.library with HLL

That is probably 0.1 molehill in size?
The integer variant I guess?

[Thomas Richter]

Originally Posted by Bruce Abbott

What does 27 times get me? The difference between an assembly time of 3 seconds and 1.5 minutes. You might call that 'next to nothing' - I call it the difference between enjoying myself and getting frustrated.

I call that "your code is organized badly". If something is so long that it takes 1.5 minutes to assemble, you should break it up into smaller modules that build faster, and then link later.

Originally Posted by Bruce Abbott

The modern programming paradigm in a nutshell - Who cares about efficiency, the most import thing is how often you push out updates.

No, the paradigm is "solve the problem". If the solution needs fast code, I write fast code, but that does not mean that I write everything in assembler. In a typical code, 80% of the execution time is spend in 20% of the code, and that code is worth looking at.

Originally Posted by Bruce Abbott

Another bad argument. This has nothing to do with asm being "outdated, unmaintained". If Daniel Weber had released the source code for ProAsm then updating it would have been a doddle.

No, it wouldn't. That' exactly the problem. You need to understand how this code works, and that is a lot easier in higher languages than it is in assembler. Actually, that is exactly the purpose of higher languages: to document intentions by syntax and to help testing constraints that are expressed by the syntax.



A good program in a suitable language is (hopefully) self-documenting, with additional checks made by the compiler. An assembler does not check arguments for correctness, it does not check pointer assignments, or proper return codes. Yet, it is helpful to make such checks as it avoids problems in complex programs.

Originally Posted by Bruce Abbott

The 'problem' I want to 'solve' is how to enjoy what time I have left in this world, and having a fast assembler is a big part of that.

That's all fine for you, but that's not how most software is created or why most software is created.

[Bruce Abbott]

Originally Posted by Thomas Richter

I call that "your code is organized badly". If something is so long that it takes 1.5 minutes to assemble, you should break it up into smaller modules that build faster, and then link later.

I call that "You must use this complicated method created to get around long compile times". I especially don't want to do that when working with disassembled programs that have to be reassembled exactly.

No, it wouldn't. That' exactly the problem. You need to understand how this code works, and that is a lot easier in higher languages than it is in assembler.

'this code' is machine code. If the original source was HLL it could be very difficult to follow without deep knowledge of the compiler (perhaps not even then). But ProAsm was written in assembler so I know the disassembly is almost identical to the original source, which makes it much easier for me to understand.

A good program in a suitable language is (hopefully) self-documenting, with additional checks made by the compiler. An assembler does not check arguments for correctness, it does not check pointer assignments, or proper return codes.

Yes, we know that. Don't program in assembler if you want your hand held.

That's all fine for you...

Exactly. The vast majority of people aren't programming in assembler, in fact they aren't programming in any language. But a large proportion of Amiga programmers are programming in assembler. Not because we have to, but because we like it - and nobody can tell us what we like.

[Bruce Abbott]

Originally Posted by Thomas Richter

Err. No. You have no idea how compilers work, and they don't work like this.

Some do, or did.

Stack Overflow: Does a compiler always produce an assembly code?

Smaller projects often choose to leave object-file format details to the assembler. e.g. FreePascal can go straight to an object file on a few of its target platforms, but otherwise only to asm...

Gcc does create the assembly code as a temporary file, calls the assembler, and maybe the linker depending on what you do or dont add on the command line. That makes an object and then if enabled the binary, then all the temporary files are cleaned up. Use -save-temps to see what is really going on (there are a number of temporary files).

[Bruce Abbott]

Originally Posted by Gorf

OK.
So far so understandable.
But:

Your A3000 was still (at least) 5x faster - so in combination with Devpac it was total speedup of 25x compared to your old setup.

Yep. The project I was working on would assemble so fast I sometimes wondered if it had done it. Took a while to get used to that.

But ProAsm is several times faster than Devpac, and Basm is nearly twice as fast as ProAsm. It's incredible to think that optimizing the software could have the same effect as increasing CPU speed from 50MHz to over 2GHz.

Not getting both in the end would lead to frustration, wouldn't it?

It was 'worth it' later because I was able to expand the A3000 with an 060 and RTG - though at extreme cost. I sunk ~NZ$15,000 into that machine - then sold it a few years later for a miserable $1,000.

If I hadn't got the A3000 I probably would eventually have bought an A1200 or A4000. But the A1000 didn't last that long because it was stolen before I even got around to setting up the A3000! (and they took all my backup disks so I had to redo the entire project from scratch).

[meynaf]

Originally Posted by Thomas Richter

Err. No. You have no idea how compilers work, and they don't work like this. Compilers create an abstract syntax representation from the input, then optimize on this abstract description.



Ever wonder what the "quad" files are the Lattice C compiler generates (and the SAS/C compiler still holds internally)? This is exactly the internal representation. It is not assembler. It is an abstract description on the program flow and the objects that are manipulated.


Only the very last part of the compiler creates object code from this abstract description, the "code generator".


So, for example, here is how SAS/C works:


"sc1" is the preprocessor and parser. Its output is the abstract description of the code, the "quad" file.


"scgo" is the "global optimizer", it optimizes beteween functoins, on the "quad" file.


"sc2" is the final code generator from the quad file.


There is no assembler at any level, it goes from quad to object code. You get an assembler as part of the package ("asm"), and even an object code disassembler ("omd"), but that's not run as part of the compilation process. You can check with SnoopDos if you want.




No, it doesn't. The gcc package comes with an assembler, "gas", but it is not required for the compiler chain. It uses a similar workflow as SAS/C, but quite a bit more sophisticated over multiple representations of the code.

Yet vbcc still uses vasm, at least the version i used - and don't tell me it doesn't, i've had assembler errors once.
HiSoft C++ also uses asm as part of the build process.

But it's not as if this was relevant anyway. Whether asm is used internally does not change the fact I can resource the code and have an asm source that will assemble and work. Or use the compiler feature to output asm.

Originally Posted by Thomas Richter

"Peephole optimization" is not a text-parsing exercise. It is the very last stage after instructions have been selected, and then another step is run on this representation. But it would be wasteful to represent the instructions in assembler mnemonics.

But it is given for free by just using an assembler, and providing a way to emit asm source is common among compiler options so representing the instructions as assembler mnemonics is a feature present in the compiler.
So at the end what is wasteful is to actually not use the asm.

Originally Posted by Thomas Richter

Not quite, as with just having object code, you still do not know what is code and what is data, or whether it is even both.

As if this were difficult to find out, especially for compiled code. Many re-sourcing tools even do most of the job automatically.

Originally Posted by Gorf

we is?
You don't, I do ...

Not that again... This is childish.

Originally Posted by Gorf

If your claims are true and 68k implementation would bring at least a 10x speedup, I would not only use it on my real hardware for fun, but also together with a 68k-emulation in production, because it still would be faster this way...

Very nice strawman fallacy you're making here.
I didn't write "at least a 10x speedup". I wrote more about 2-4 times faster in average, sometimes more.
That said, i wouldn't be surprised if winuae with jit sometimes provides better performance on some Amiga apps than what we can get from their 'native' bloated counterparts...

Originally Posted by Gorf

You defined the unit molehill yourself.
(1 molehill = 1 CouchDB clone in handcrafted 68k assembler)

No i didn't define it. Do not overinterpret what i write.

Originally Posted by Gorf

It has SMP multiprocessor support and memory protection.
Which brings us even back to the topic: Vampire/Apollo
According to Gunnar his 68080 has already hyper-threading and is SPM-ready ... only AmigaOS can not make use of it.

I don't care about SMP support and memory protection

Originally Posted by Gorf

Concrete suggestions (in molehill size)?

Only suggestion i can make here is that you stop this nonsense.

Originally Posted by Gorf

As for Ratatouille, Toby, Loki, ExCLI and Numerix: YES

This is having them for the sake of having them. You wouldn't really use them.

Originally Posted by Gorf

But your framework does not exist on Atari or Mac ... so again we will never know...

It does not exist maybe, but guess what i use when porting code from either of those two...

Originally Posted by Gorf

OK ... so only for the inner circle ...

If you're jealous, build your own tools to do the same.

Originally Posted by Gorf

In the end by forcing people to recompile their software or abandon it.
Like they did then with PPC on x86 and now with 32-bit ARM and x86 and will do with x86_64 in a while.

Ever heard of Rosetta ?

Originally Posted by Gorf

to clear any doubts.

You do not look like you're having any doubt.

Originally Posted by Gorf

That is probably 0.1 molehill in size?

Then i just write a program that supports 10 formats (=10* 0.1) and you're satisfied ?

Originally Posted by Gorf

The integer variant I guess?

Of course the integer variant, not all 030s have fpu. Integer is also faster.

[phx]

Originally Posted by Thomas Richter

No, it doesn't. The gcc package comes with an assembler, "gas", but it is not required for the compiler chain.

Interesting. Last time I checked, the gcc frontend calls "as" to assemble the compiler output from a temporary file, just like most compilers do. But maybe this changed with later versions or on different backends?

Originally Posted by meynaf

But it is given for free by just using an assembler, and providing a way to emit asm source is common among compiler options so representing the instructions as assembler mnemonics is a feature present in the compiler.
So at the end what is wasteful is to actually not use the asm.

I would agree here. When SAS/C doesn't do that, then there is a lot of unnecessary complexity in the compiler. Peephole optimization, like deciding whether a branch fits into 8 or 16 bits, is really nothing the compiler should be bothered with. Intermediate code is much easier translated into mnemonics than doing all possible optimizations on object code level. Crazy...

[Promilus]

@phx - it surely works without as.exe for x86 on codeblocks with it's own mingw I installed long long time ago (so no, not the newest version which I don't even know which it is now, at some point of the time both gcc and wine got rapid version changes I lost count).

[pandy71]

Nice discussion but please correct me on two things, first how ongoing discussion is related to 'Apollo Maggie 3D Chip' and secondly isn't approach where high level language (HLL) is used together with some heavily optimized intrinsic's (asm/LLL) seem to be most optimal way of the software development?

btw is there any profiler for Amiga so code can be objectively analyzed in terms of used cycles and as such programmer may begin to optimize most CPU hungry parts?

[Promilus]

how ongoing discussion is related to 'Apollo Maggie 3D Chip'

It is not related at all

isn't approach where high level language (HLL) is used together with some heavily optimized intrinsic's (asm/LLL) seem to be most optimal way of the software development

It is for those who can efficiently use both. Nevertheless 100% asm will get faster code, 100% hll will get code faster*

*-slight exaggeration

btw is there any profiler for Amiga so code can be objectively analyzed in terms of used cycles and as such programmer may begin to optimize most CPU hungry parts?

Probably only commercial IDEs like CodeWarrior for Embedded 68k. If any.


edit - my bad, just checked out Abyss plugin for VSCode and indeed it does have pretty amazing tools for Amiga C developers up there.

[deimos]

I would just like to know why the moderators have allowed this thread to go on like this.

Is it because they are afraid of hurting certain peoples' feelings? Or because they are just absent?

Whether or not the Apollo / Vampire stuff is for you, can't we just appreciate what these hobbyists have achieved? If I had half the skill that they do I'd want to show it off, but I know I never would now, because it will just turn into a wankfest with the thread being derailed with pointless, endless arguments about whether one basement dweller can write code in an obsolete assembly language better than another can code in a totally incomparable high level language that probably can't even be compiled to the same CPU.

[Promilus]

There's not much about that softcore implementation going around except it does some minimum one might expect from 3d accelerator (like voodoo - with texture mapping and pixel filling + texture filtering). So starting from that it was fairly obvious that when we talk about what software can we run with it we think rather about PC ports and from early pentium era (and not brand new titles tailored to AMMX, SAGA and MAGGIE). Mentioning pentium lead to performance discussion, ISA discussion and that lead to war of asm vs c which took several pages now. I believe anyone presented very well their own opinion about that and we can (finally) let it rest.

[pandy71]

Originally Posted by Promilus

It is not related at all

Well, to be honest any new functionality for Amiga, even incompatible and very niche is very appreciated by me so i was simply curious about this new baby from Apollo.
Of course this was also my very first, ignored question about comparison with other new 3D babies available for Amiga (mostly those in or Raspberry PI or for example Beaglebone).
I'm fully aware of the FPGA limitation and of course lack of many features present in dedicated 3D cores but it could be interesting as seem Apollo Maggie can be lowest common denominator and as such at some point bias or specifically shaped hypothetical 3D in Amiga.

Originally Posted by Promilus

It is for those who can efficiently use both. Nevertheless 100% asm will get faster code, 100% hll will get code faster*



*-slight exaggeration

I think there is no warranty that asm code will be always fastest... for sure asm is more challenging from long term code maintenance perspective.

Originally Posted by Promilus

Probably only commercial IDEs like CodeWarrior for Embedded 68k. If any.
edit - my bad, just checked out Abyss plugin for VSCode and indeed it does have pretty amazing tools for Amiga C developers up there.

Thx! this is truly neat solution - so it could be nice to compare code efficiency in large project - objective tool to do verification exist.

[grond]

Originally Posted by deimos

I would just like to know why the moderators have allowed this thread to go on like this.

Is it because they are afraid of hurting certain peoples' feelings? Or because they are just absent?

Whether or not the Apollo / Vampire stuff is for you, can't we just appreciate what these hobbyists have achieved? If I had half the skill that they do I'd want to show it off, but I know I never would now, because it will just turn into a wankfest with the thread being derailed with pointless, endless arguments about whether one basement dweller can write code in an obsolete assembly language better than another can code in a totally incomparable high level language that probably can't even be compiled to the same CPU.

This sort of thing always happens with any Vampire-related topics. The same people always show up. If you start arguing with the bunch in favour of the Vampire, the thread will then be pointed out as proof how the "Vampire fanbois" always turn everything into a flame fest.

[indigolemon]

I'm not a fan of the Vampire, so I generally just avoid these threads, but I skimmed this one and frankly it's utterly mental

[eXeler0]

Originally Posted by indigolemon

I'm not a fan of the Vampire, so I generally just avoid these threads, but I skimmed this one and frankly it's utterly mental

You know its bad when even the moderators be like "Hell no, I ain't touching that"

[S0ulA55a551n]

Originally Posted by eXeler0

You know its bad when even the moderators be like "Hell no, I ain't touching that"

we have moderators! ?

[dreadnought]

Actually, the squabbles over Vampire (which this derail isn't really) are at least somewhat entertaining. Splitting hair over some obscure coding conundrums, using half-page long multi-quote posts, not so much.

I don't see anything that would really require moderation here though, unless maybe splitting this topic into a separate thread.

[Mathesar]

My only concern regarding this thread is that I am out of popcorn.

[Promilus]

@Mathesar
"I've come here to eat popcorn and give bans and I'm fresh out of popcorn"