[UserReview] Vampire V2-128 received and it's just pure p0rn.

[OlafS3]

Nothing evil going on, stop with the hyperbole. I was there on irc when all this went down, I still have the logs.

Kolla you explained already thousands of times how unhappy you are with the direction of vampire and that Gunnar is a liar and you bought it with different expectations. I already asked you several times to sell your vampire so you have no longer reason to moan and cry on every amiga site, you get your money and there is a new vampire owner who is happy with what he gets. A win for everyone. You did not react on it instead you continue the same. To me it looks like spreading nonsense on websites is your main interest in your life. Very poor...

[OlafS3]

The fact that you keep irc logs tells more about you than about what was said on irc.

Kolla will never contribute anything to the project. Crying is his main interest and makes him feel important

[guest11527]

A full 882 inplementation is a waste of gates. An 040 compatible FPU is all that is really needed. The 68882 transcendental instructions were so chronically slow anyway that you'd be certifiable to use then over any half decent software solution that uses simpler FPU operations.

It is a bit more complicated than that, though. The 68882 has dedicated logic for it, essentially the cordic algorithm, and goes by microcode through the cordic tables. This by itself is not a slow algorithm. The 68040 left this out. The software emulation is using a completely different type of algorithm that is based on polynomial approximations, and it is better suited for software than cordic - which is a hardware/table-driven approach.

Hence, one cannot really say that the software solution is "simpler". It is different, and better suited for software.

Some sort of trap and patch like oxypatxher/cyber patcher would be a nice way to get performant support for old 882 dependent code. It was good enough for the 040/060 after all.

The reason why MuRedox helps improving the speed is not that it uses a more optimized implementation of the FPU core. The main reason is that it avoids the exception overhead (on the 68040) and the need to decode the instruction manually (on the 68060). I suppose neither of that is really necessary on the Apollo core, thus there is likely less to gain by such a solution - at least if Gunnar had the math emulation implemented as I suggested, i.e. with direct access to the CPU pipeline.

As far as I got the story, the part that is otherwise slow in software on the 68060 (namey the manual instruction decoding) is not necessary, and the rather large stack frame of the 68040 is also avoided.

The only drawback may be that the FPU handling is an exception, i.e. multitasking stops.

[guest11527]

I think you are missing the point. Full 882 emulation is just a waste. Can you show me any software released since people first started putting 040 and 060 in their systems that still needs needs a full 882 and doesn't have a version compiled that either does not require an FPU at all or relies only on the 040/060 subset?

Frankly, I do not believe that anyone has a full overview, but instructions like fsin or fcos are still quite necessary for 3D games. Is it really that people checked for alternatives for them?

I
Is there a valid reason why the FPGA implementation could not implement it's own patch to call out to a handler routine when an unimplemented opcode is  first encountered?

Uglyness of the design? I do not see much sense in the CPU core modifying the program it is executing. That can be done by a pure software solution.

The trap solution for less frequently used instructions is not bad per se, and it can surely be done in a better way than on the 68040 or 68060.

[grond]

The only drawback may be that the FPU handling is an exception, i.e. multitasking stops.

How much multitasking is there while the 882 executes a 600 clock cycle fsin? How much multitasking is there while the 040/060 executes a trapped fsin? To how much time do the clock cycles without multitasking amount in any of 030, 040, 060 and 080 considering the different base clock frequencies? I guess we should not forget that instructions that are 882 but not 040 are deprecated and only supported for legacy reasons. Their use is discouraged either way.

[grond]

Frankly, I do not believe that anyone has a full overview, but instructions like fsin or fcos are still quite necessary for 3D games.

Not really. You need sine computations once per frame and perhaps once per lightsource and frame for more complex 3D games, but from then on it is usually all fmul/fadd.

[guest11527]

How much multitasking is there while the 882 executes a 600 clock cycle fsin?

All of it. The fun part about the 68882 is that it can stop its execution in the middle, save its state to its stack frame and continue from that point on, hence the 68882 is used preemptively and it is preempted as part of the exec task scheduler. Even more so, the 68882 is completely assynchronous, meaning that the FPU instruction only triggers the execution while the 68K is executing its own code in parallel. The 68K has only to wait as soon as you want to access the result, i.e. save it to memory or load it into a 68K register.

How much multitasking is there while the 040/060 executes a trapped fsin?

None of it, as it is executed in supervisor mode, and task switching does not take place while the CPU is in super mode. While it does not sound much, it is noticable by a the mouse pointer no longer moving smoothly if the fpsp is in heavy use. MuRedux can certainly help here. In principle, one can restructure the fpsp such that it switches back to user mode after having done all the supervisor-only business, as in fetching the data and validating the addresses. I tried this once, but the net effect of this wasn't as great as I was hoping as switching back and forth is neither a "for free" operation.

To how much time do the clock cycles without multitasking amount in any of 030, 040, 060 and 080 considering the different base clock frequencies? I guess we should not forget that instructions that are 882 but not 040 are deprecated and only supported for legacy reasons. Their use is discouraged either way.

I never saw a deprecation notice from Motorola, Freescale or NXP on these instructions, so I wouldn't say so. That they didn't put them into silicon is just a tradeoff between completeness and available silicon area/available gates.

[grond]

Some facts:

Code: [Select]

        68882                                  68080         Clock cycles     Latency @50 MHz       Clock cycles     Latency @80 MHz fadd              56             1120 ns                  1             12.5 ns fsub              56             1120 ns                  1             12.5 ns fmul              76             1520 ns                  1             12.5 ns fdiv             108             2160 ns                  2             25   ns fsqrt            110             2200 ns                222           2775   ns fmove             21              420 ns                  1             12.5 ns fsin             394             7880 ns                254           3175   ns fcos             394             7880 ns                269           3362.5 ns fsincos          454             9080 ns                317           3962.5 ns  Who can add the values for 25 MHz 040 and 50 MHz 060?

[grond]

Some facts:          68882                                  68080         Clock cycles     Latency @50 MHz       Clock cycles     Latency @80 MHz fadd              56             1120 ns                  1             12.5 ns fsub              56             1120 ns                  1             12.5 ns fmul              76             1520 ns                  1             12.5 ns fdiv             108             2160 ns                  2             25   ns fsqrt            110             2200 ns                222           2775   ns fmove             21              420 ns                  1             12.5 ns fsin             394             7880 ns                254           3175   ns fcos             394             7880 ns                269           3362.5 ns fsincos          454             9080 ns                317           3962.5 ns  Who can add the values for a 25 MHz 040 and a 50 MHz 060?

[grond]

Some facts:

Code: [Select]

       68882                                  68080
        Clock cycles     Latency @50 MHz       Clock cycles     Latency @80 MHz        ratio
fadd              56             1120 ns                  1             12.5 ns        89.6x
fsub              56             1120 ns                  1             12.5 ns        89.6x
fmul              76             1520 ns                  1             12.5 ns       121.6x
fdiv             108             2160 ns                  2             25   ns        86.4x
fsqrt            110             2200 ns                222           2775   ns         0.8x
fmove             21              420 ns                  1             12.5 ns        33.6x
fsin             394             7880 ns                254           3175   ns         2.5x
fcos             394             7880 ns                269           3362.5 ns         2.3x
fsincos          454             9080 ns                317           3962.5 ns         2.3x
Who can add the values for a 25 MHz 040 and a 50 MHz 060?

[Karlos]

Again my point has been missed here. Show me any 3D game on the Amiga that requires floating point (as opposed to doom like fixed point which uses approximations for trig etc) that actually uses 68882 transcendental trig functions as opposed to being optimally compiled for 040/060.

Games like Quake that use proper floating point trigonometric operations for vertex processing were already utterly useless on anything less than a 68060. The developers certainly weren't going to make that worse by using unimplemented 882 opcodes in their binaries.

Maybe, just maybe, there's an F1GP or TFX build that uses 882 for this.

[grond]

The above values are for the Gold 2.7 release of the 68080. The V4 release of the 68080 can schedule one fsqrt per cycle and complete it in 20 cycles.

[soviet]

Man Kolla sure have lots of free time, he can troll on this vampire thread 24 hours a day 365 a year its quite impressive.

[Lord Aga]

Yall poor sods think you can beat Kolla in the truth game? He's squatting in Gunnar's closet, taking notes and saving logs. He even knows what Gunnar mumbles in his sleep. Which, obviously, makes him more knowledgeable about Gunnar than Gunnar himself!

[PPC]

Man that Kolla guy is tiring, whining like a little kid that didn't get her cookie.
So next up is he'll start about the MMU (again....)

[kolla]

Firstly, IRC logs come for free when you use irc services like znc etc, not like I hang out logging manually using amirc or whatever.

Secondly, I have nothing against software emulation of 68882 instructions, that's after all what we have been doing since 040 and it works well.

Apollo Core has FPU like 68040 and hence need a similar solution as 040 and 060. No problem.

But then, do not run around claiming that NO software emulation is taking place with Apollo Core on V2, because that is simply not true. Unless 68882 is actually implemented, which would be worthy a news item.

Lastly, the software emulation of 68882 instructions are not running within the scope and and reach of the operating system. It's not a task of AmigaOS. It's not visible for any OS running on the Vampire card. If you use old software to try detecting what CPU there is, it may very well say it's a 040+882. Now, one can question wether it is a good or bad thing to have emulation software - or any software at all - running outside, or "under" the operating system. Some would say that is crawling towards using a hypervisor. There has also been talks about hyperthreading. Well, AmigaOS cannot do it by itself, so something else would be needed to do the scheduling etc of "out of bounds" threaded processes. Again, it is tempting to call that a hypervisor. Is this good or bad? I don't care, it just is what it is. I am skeptical though, as all experience says that running software outside the reach of the operating system complicates a number of things.

As for MMU, it is already there, it just isn't compatible with existing software and operating systems, which is a case of lost opportunities for Apollo Core. Not for me, but for Apollo Core and for Gunnar. His problem. Not mine. The MMU of the Apollo Core is used on the Vampire cards, is (among other things) used for mapping memory, so that AmigaOS, drivers and software can run happily. Nice solution and works great. Also it has been mentioned that MMU is involved in for example speed up IDE and do various DMA tricks. Also cool. All this happens outside the scope of the operating system. There are a few libraries and resources giving limited access to the Apollo Core MMU, like softkicking for example. But again, it is starting to look like some hypervisor model.

Social aspect of the Apollp Team, who have more speaks persons than they have people doing actual work, and who contradict each other and Gunnar half of the time... yeah, it speaks to itself. Grong, no testing? Apollo-accelerators.com says/said something else, and luckily there is wayback machine.