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

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

[grond]

Apollo Core does 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.

 Nobody has ever claimed that 68882-only FP instructions will be implemented in dedicated hardware. And yet the way these instructions are implemented in the 080 is more similar to the way it is done in the 68882 than to the way it is done in the 040 and 060. There is no trap, no trap handler, there is microcode that uses more fundamental operations such as fmul, fadd, fdiv. The 68882 is exactly like that! It is all microcoded just that in the 68882 the microcode is stored as a metal mask ROM while in the case of the 080 the microcode is stored in flash memory.

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.

 Even Intel processors are full of microcode. So even if one could question that, the answer to that would be clear anyway: it doesn't matter and it is no problem.  

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.

  And the problem is what? That there is also work done to use a CPU feature in AmigaOS? The alternative would be to not use the CPU feature. Possible but no advantage.  

I am skeptical though, as all experience says that running software outside the reach of the operating system complicates a number of things.

 Actually it is not SOFTWARE running outside the reach of the operating system that complicates things, it is having different processes/functional units operating concurrently that makes things complicated. The Amiga has always suffered from bad handling of blitter tasks running in parallel to the CPU and badly managed DMA. It doesn't change anything if such tasks are handled by dedicated hardware or by software running in a hyperthreaded virtual CPU core invisible to AmigaOS because it doesn't know about hyperthreading or multiprocessor environments.

As for MMU, it is already there, ir just isn't compatible with existing software and operating systems, which is a case of lost opportunities for Apollo Core.

 It is NOT a lost opportunity. It is just NOT FINISHED. Is this really so hard to understand? The 68080 has two memory controllers. No other 68k CPU has ever had a memory controller and most certainly not two running concurrently. An MMU running in such a processor needs to be different from the MMUs that previous 68k processors had. This is a technical fact. At the same time a modern MMU needs features such as marking memory as non-executable and such. Again: this project is not about the Amiga, it is about the 68k processor family. It does not matter whether AmigaOS has no concept of memory protection and thus does not need non-executable memory protection. The fact that AmigaOS does not make use of this MMU feature has no influence on the decision whether this feature will be implemented or not. But perhaps if we are lucky and patient, there will eventually be a compatibility MMU-layer on top of the units that are already there. Maybe this layer will support all MMU-features the Amiga has used, maybe only some.  

And again: ALL of this has been explained many times before.  

Also it has been mentioned that MMU is involved in for example speed up IDE and do various DMA tricks.

  Um, this sounds like you are mixing things up. I don't think the MMU has anything to do with IDE. The MMU certainly plays a role when dealing with DMA.  

Grong, no testing? Apollo-accelerators.com says/said something else, and luckily there is wayback machine.

I guess you are referring to the tests of the individual FPU instructions. This is not testing the FPU. This is basically using pseudo-random generators to produce e.g. two sources of input data and feeding that into the hardware unit that does the FADD. Then compare the output of the FP-adder to the expected result (precomputed or some other reference, e.g. calculated by some Intel or 68k FPU). The comparison is done automatically. Such testing was done for millions of testcases by Chris who developed most if not all of the FPU units. This testing took place but was not done by the team. Hence, it is a correct statement that there had never been any FPU testing done by the team until FEMU was started. Furthermore, this automated testing, although certainly difficult to set up, is less work than testing how program flow behaves, whether flags are set and evaluated correctly, whether operand prefetch goes wrong in certain situations, whether pipeline forwarding between consecutive FP instructions works and so on. The latter is what has been going on in the last few months.

Just because you don't understand how the work of developing a CPU is done in general and in this specific project, doesn't mean that there are self-contradicting statements, hidden truths and dirty secrets that would require YOU to unveil them.

[guest11527]

Nobody has ever claimed that 68882-only FP instructions will be implemented in dedicated hardware. And yet the way these instructions are implemented in the 080 is more similar to the way it is done in the 68882 than to the way it is done in the 040 and 060. There is no trap, no trap handler, there is microcode that uses more fundamental operations such as fmul, fadd, fdiv. The 68882 is exactly like that! It is all microcoded just that in the 68882 the microcode is stored as a metal mask ROM while in the case of the 080 the microcode is stored in flash memory.

That's not how I understood the story, but maybe you want to elaborate. To my understanding, this is just regular 68K code that is stored in ROM, not "microcode". This makes in so far a difference as 68K code will depend on additional resources, i.e. it will require some stack to save back register contents, it might be interrupted... etc. For most practical reasons, this might not make too much of a difference, unless you attempt to do really crazy things such as "fsin.x -(a7),fp0", i.e. instructions that contradict the way how the 68K operates.  Of course, the same restrictions apply to the fpsp, so nothing of that is really new. The advantage of the fpsp code is that it can be very easily updated in case someone finds a defect. The same goes, of course, for modern microcode once you have tools how to get it loaded into the CPU and make such tools available to the user.

Actually, this did happen in the past once to me, and we also found a bug in the P5 libraries during beta-testing, so it is not quite academic as an argument as it may sound. It also happened to intel a while ago, as you know. (-: Which was one of the reasons why they made microcode upgradable from external sources.

Second, due to that, the way how the result is computed is certainly different from that how a 68882 performs its job. The latter is cordic, the former is a polynomial approximation. Again, that does not make much of a difference as long as the result is correct, but it is certainly not "the same".

[grond]

Sure, all analogies and comparisons fail if you apply a higher zoom factor. That doesn't prove the point moot. And I wrote that the way it is done on the 080 is more similar to the 882 than to the 040. And this is still correct. The emulation code could not be executed by any of 68000 through 68060 because it makes use of features unique to the 080. E.g. it uses additional FP registers and instructions that do not exist on any previous 68k FPU. In fact the correct technical term is not "microcode" but "millicode" and is widely used in modern CPUs. Did we really need to discuss this?

[guibrush]

@kolla :
Please, get a life and stop spreading false statement. I reported your post to the admins and I encourage the others that are annoyed too to do the same.

[guest11527]

Sure, all analogies and comparisons fail if you apply a higher zoom factor. That doesn't prove the point moot. And I wrote that the way it is done on the 080 is more similar to the 882 than to the 040.

This is, of course, very much a matter of personal taste. Again, not saying that it makes much of a practical difference, but microcode operates on quite a different level than (albeit extended) 68K code as it has access to the internal register routing of the CPU.
As in the 68040/68060, we are just executing 68K code, one in ROM, the other loaded in RAM, both triggered through an exception - so for me this brings it pretty close to the 68040/68060 library, except that upgrading the code is probably not quite as straightforeward as it was for the libraries.

Every model has its advantages and drawbacks, I do not make a particular statement for one or the other. But "just like the 68882" is certainly not right. A different algorithm, and a different execution model.

Did we really need to discuss this?

Why not? I think it's fairly interesting. Again, I'm not saying that this is any better or worse. Probably Microcode would have provided more options to mess with the CPU resources, but then again... why bother.

[Zooz]

Hi Thomas

Some words about "except that upgrading the code is probably not quite as straightforeward as it was for the libraries."

Not sure it really matter since in all cases, such updates would need team collaboration, where of course they know how to update it. And if you meant that it needs a new core to upgrade it, it does not actually. There is a accessible vector for that, and can be 'hot' overwritten.

[Karlos]

So, my thoughts were based on an assumption that a full 882 implementation is a lot of work and would use up a lot of gates that could be used for other stuff and the fact that most people that really needed FPU had migrated to 040 and 060 based machines and recompiled binaries that no longer used unimplemented FPU operations.

If that's not correct, then great, 882 me up.

Eagerly awaiting an A1200 version!

[Zooz]

The 080 fpu is the first ever 68k fpu in an (amiga targeted) fpga. Personally i find this a good news and is welcomed. It also was done with constraints in mind. Whatever solution the team selected they did because of constraints they knows and solved and well. The result is a fpu that already reached a nice level of compatibility. It covers all the existing fpu instructions from 881 to 060. The 881/2 instructions are covered with solution that do not 'eat' fpga space while being faster than any existing library.

[guest11527]

So, my thoughts were based on an assumption that a full 882 implementation is a lot of work and would use up a lot of gates that could be used for other stuff and the fact that most people that really needed FPU had migrated to 040 and 060 based machines and recompiled binaries that no longer used unimplemented FPU operations.

It's neither quite adequate because you seem to assume that the 68882 is a complete hardware implementation. It is not, and has never been. The 68882 has hardware support for some elementary FPU operations, plus a lot of tables, plus some ROM-based microcode. Nobody sane in his mind implements a full FPU in hardware. That was not the case for the 68882, nor for the 68040. The difference was just where "the software runs". For the 68882, it runs as microcode in the ROM of the chip. For the 68040, it is 68K code in the 68040.library. And "what the software does". For the 68882, it uses an algorithm known as "cordic" which is mostly table driven (i.e. very simple software). For the 68040, cordic was replaced by polynomial approximations, which requires fewer steps in software, but more complicated steps like multiplications. There are no multiplications in cordic.

Now, the Apollo core uses another variation of this scheme as it seems. It is again 68K code, though run in a ROM.

Just to complete the picture: Even the 68000 CPU is not a complete hardware implementation. It is driven by microcode that "runs" on a simpler machine. The 68060 was a complete hardware implementation, with known side effects on "correctness". Software is always easier to get right.

Also, "mathtrans.library" on the Amiga is a cordic implementation, because the multiplication on the 68000 is relatively expensive. "mathieeedoubtrans" is polynomial approximation - it is designed for faster CPUs. So you find all the models in AmigaOs as well.

[psxphill]

The difference was just where "the software runs". For the 68882, it runs as microcode in the ROM of the chip. For the 68040, it is 68K code in the 68040.library.

Only some of it is 68k in the 68040.library, some of it is implemented in hardware. Less of it is implemented in hardware on the 68060, I'd settle for vampire being compatible with the 68060. I'd like to be able to switch to 68040 though because there are times when you can't run any emulation software.

The 080 fpu is the first ever 68k fpu in an (amiga targeted) fpga.

It's a software emulated fpu. Those have existed for years.

So, my thoughts were based on an assumption that a full 882 implementation is a lot of work and would use up a lot of gates that could be used for other stuff and the fact that most people that really needed FPU had migrated to 040 and 060 based machines and recompiled binaries that no longer used unimplemented FPU operations.

If that's not correct, then great, 882 me up.

Eagerly awaiting an A1200 version!

Your assumption is wrong.

The 040 & 060 cpu can still run some of the 68882 instructions & emulates some of them, while vampire can run none of them and emulates all of them. If vampire could run all 060 or 040 instructions without emulation then this discussion wouldn't exist.

[Zooz]

It's a software emulated fpu. Those have existed for years.

Lol no. Speaking of Gold2.7, it is hardware implemented. Quite all 040 fpu instructions are, all Ea modes are, Registers are. It is clear that only some 881/2 instr are software emulated. And even for the emulated ones they benefits of the hardware implementation. EA computation is done by hw for example, and also castings and primitives,  which helps lower (and simplify)  the emulation overhead by an important factor.

[ferrellsl]

Looks like Kolla has done another fine job of derailing a thread with his rants....

[guest11527]

Only some of it is 68k in the 68040.library, some of it is implemented in hardware. Less of it is implemented in hardware on the 68060, I'd settle for vampire being compatible with the 68060.

Actually "something different is implemented in hardware in the 68060". If I recall correctly, one instruction was removed from the 68060, and another was added. In general, however, the EA computation was removed from the 68060 completely and has to be done in software. The 68040 does this in hardware, but writes a long and complicated stackframe in exchange. Neither is a perfect solution.

It's a software emulated fpu. Those have existed for years.

Hardly, because then it wouldn't be able to get one clock cycle for elementary arithmetic instructions . However, from what I know, I afraid that this is only a 64bit FPU, i.e. results may differ from the full 80 bit implementation Motorola provided. Again, "in typical applications", this may not make much of a difference.

[Crom00]

"I started out as super enthusiastic, but ended up reluctant. I appreciate the accomplishments, but I am not thrilled about the attitudes and skeptical about the agenda." -Kolla

So here we are a couple of years later since the start of this thread and the overall mindset of Kolla remains the same.

I am happy with my Vampires, so if you are reading this thread and are on the fence about getting one.

I can say that after having spent the past two years on Vampires and as an owner of every Amiga model out there...Buy the Vampire for the features it has right now, and that feature set is pretty good, better than good actually.

[johnklos]

You know, there are some of us who agree with Kolla and don't see the need for all this defensiveness about the Vampire.

I, for one, want a compatible CPU, FPU and MMU. I don't see gcc being adapted for the special instruction set of the "080", particularly since the instruction set is still changing. Likewise, there's no way anyone is going to spend even a tiny bit of work caring about the special case of an "080" for LLVM - all energy is going in to generating code than can run on real m68k chips. If an emulation or an FPGA implementation can also run code that runs on real m68k chips, then great!

All this talk about memory controllers requiring a different kind of MMU is bull. You're conflating issues. A memory controller needs access to things that an MMU needs to do, but this does not require a reinvention of an MMU. There's no good reason whatsoever that an m68k compatible MMU can't also support the needs of a memory controller (or multiple controllers) without making the MMU incompatible from the point of view of the running OS.

What I'm getting at here is that there are all of these apologists for the Vampire that are pretending that there are reasons why a non-standard MMU and non-standard FPU are somehow "necessary", when it's nothing but bull. What each and every apologist here is missing is how this is going to mean the Vampire will miss out on helping with real projects such as gcc, LLVM, and all the cool tools and software that come with a proper suite from each of those.

Also, there's no good technical reason that I can imagine or have seen here or anywhere else that suggests that anything but a superset of the m68k instruction set is necessary. Add features all you want, but trying to say that they have to come at the expense of compatibility is specious at best and willfully ignorant at worst.

Kolla has a tremendous amount of patience to deal will all of the apologists. I'd have given up a long time ago. I don't even have anything else to add here besides this until there are Vampire options that can run m68k code properly. It's of interest to me personally when I can run NetBSD on it and work on testing toolchain issues.

One day, we'll make another ixemul library based on modern NetBSD and we'll again have a way to compile and run lots of free and open source software on AmigaDOS.