@Barana: nothing to say about it. It's a HUGE improvement compared to the existing 68K processors. Kudos for the achievement.

I don't agree with some technical choices but, as you said, everyone has proper opinions.

@cdimauro

"magically appeared".

You know, development takes time. Everyone wants THEIR favorite feature to be included NOW etc.

Yes, Gunnar got fed up with the nagging, and said "NO FPU for you!", but that seemed like it was more him venting frustration than anything else. Plus, when Jari decided to make a softFPU, it shared the workload, which accelerated implimentation.

And before someone comments "Its not professional to loose your temper"; Hes just human, like all of us.

Last edited by Overflow on 16-Sep-2018 at 11:13 AM.

@Overflow

The big mistake was announcing the FPU (and not just announce it, but glamour it, brag about it, fastest bestest FPU ever) as almost ready, literally years before it was anywhere near ready. And then backpadling the whole issue with "no software use it anyways" and name calling those who say software emulation is not a satisfactory solution.

And here we are, FPU issue is *still* not anywhere near "finished" or resolved.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Overflow

Quote:

Overflow wrote: @cdimauro "magically appeared". You know, development takes time. Everyone wants THEIR favorite feature to be included NOW etc. Yes, Gunnar got fed up with the nagging, and said "NO FPU for you!", but that seemed like it was more him venting frustration than anything else. Plus, when Jari decided to make a softFPU, it shared the workload, which accelerated implimentation. And before someone comments "Its not professional to loose your temper"; Hes just human, like all of us.

I know very well how the things went, and you also know it as well since you participated to the infamous thread on aros-exec.
So, please, don't try to justify Gunnar decisions as well as the lies that he spread all over the time (FPU was only the most known and discussed one).

@kolla

Quote:

kolla wrote: @Overflow The big mistake was announcing the FPU (and not just announce it, but glamour it, brag about it, fastest bestest FPU ever) as almost ready, literally years before it was anywhere near ready. And then backpadling the whole issue with "no software use it anyways" and name calling those who say software emulation is not a satisfactory solution. And here we are, FPU issue is *still* not anywhere near "finished" or resolved.

*

BTW, now "magically" the FPGA has space to improve FPU precision as well.

Lies, lies, pretty lies...

Quote:

kolla wrote: And here we are, FPU issue is *still* not anywhere near "finished" or resolved.

True.

I believe, selling the Vampire2/Apollo without FPU or MMU would be OK.
It's the best accelerator for the A500/A600 and the best GFX card ever made.

This might be questionable on an A1200 or A4000 but none of those former cards are available.

I don't know why the Apollo team is badmouthing MMU, FPU or PPC, they should just make their CPU with best compatibility in mind and everything would be OK.

Last edited by OneTimer1 on 16-Sep-2018 at 11:40 AM.

@kolla

The Apollo team are what once would have been termed a skunkworks project or development team Creating a new CPU/chipset onto FPGA takes lots of talent and loads of time.and As I understand it, is not finished yet, and will take two more weeks tm.It can be easy to fall into the trap of condemning/negatively criticizing, and hard to climb out , in my experience.
How about encouraging those who work on it who are vastly more talented than you. ... Or I.
But you know that Mr Kolla, or should I say Mr troll-under-the-bridge ;)

_________________
Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.

I serve King Jesus.
What/who do you serve?

@cdimauro

I note with thanks your cordiality to me in your previous response.

I ask you extend the same cordiality to Gunnar, who Is a genuine amigan - used to hang out quite a bit before you joined aw.net and made friends with many of us.
He and his team who haven't finished yet, have talent I only dream of.

Unless,of course you'd like to produce today for us an 080 core that rivals or betters his?
Again,, thankyou for the cordiality you showed me today,Could we throw some Gunnar's way? An industrious Amigan?

Last edited by Barana on 16-Sep-2018 at 11:47 AM.

_________________
Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.

I serve King Jesus.
What/who do you serve?

@Barana

Quote:

Barana wrote: How about encouraging those who work on it who are vastly more talented than you. ...

Encouraging won't help, they have their own circle of fans and believers creating a reality distortion field, blinding the Apollo team and keeping them away of the majority of possible customers.

Instead of clear fixed development targets they already seemed working on their own fantasy ISA expansions, but the VampireV4 is now delayed for more than a year.

Last edited by OneTimer1 on 16-Sep-2018 at 11:48 AM.

@OneTimer1

Oh... I think Gunnar is mature enough to not collect sycophants and MANipulators around him. He keeps the conversation in check, and chucks out unreasonably negative trolls.As we've seen.

I also seem to recall no concrete finish time for the project. And detesting any improvement to the isa in the name of feature creep , as it is a commercial enterprise the Apollo team are running, is fruitless, and will get you grumpy, not the Apollo team.
I think creating a new CPU that is more compatible with each CPU than the 020 030 040 and 060 is with the 68000 Is a stunning achievement which Motorola could not even do.
Have a beer, chill out and play an adventure game. ;)

Last edited by Barana on 16-Sep-2018 at 12:03 PM.
Last edited by Barana on 16-Sep-2018 at 11:58 AM.

_________________
Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.

I serve King Jesus.
What/who do you serve?

@Barana

Quote:

Barana wrote: I also seem to recall no concrete finish time for the project.

Posted on 20 Aug 2017

The mass production of the Vampire4 started now.

Shipping will start SEP/2017

Link:
http://www.apollo-core.com/knowledge.php?b=1¬e=8126

Last edited by OneTimer1 on 16-Sep-2018 at 01:02 PM.

Sorry for the strange formatting, forum script won't let me correct it.

According to Gunnar's posting the shipping of the VampireV4 must have started one year ago.

Link:
http://www.apollo-core.com/knowledge.php?b=1¬e=8126&x=0

Last edited by OneTimer1 on 16-Sep-2018 at 01:08 PM.
Last edited by OneTimer1 on 16-Sep-2018 at 01:07 PM.
Last edited by OneTimer1 on 16-Sep-2018 at 01:07 PM.
Last edited by OneTimer1 on 16-Sep-2018 at 01:06 PM.

@OneTimer1

Oh, I was under the impression v4 boards had been released.
You have not got yours yet?
If they are not released yet, it will only give you more time to save.

So all this negativity is because you haven't received yours yet? Good things truely come to those who wait.
I moved into a boat this year.
Do you know what its like to live in a tent/car (one of them leaky) for 14 years so you can save to live in more permanent housing?
Truely. Good things DO come to those who wait.
I own it outright and everyone my age I know is paying off a 30 year bankloan or is renting.
Meanwhile, there are plump fish swimming under said boat I need to learn how to outwit.
Wampire vill come!

_________________
Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.

I serve King Jesus.
What/who do you serve?

@matthey
Quote:

Let's compare some code with address register sources open. The following is code to determine if an address in an address register is odd (d0 is 0 for even and 1 for odd). A: move.l a0,d1 moveq #1,d0 and.l d0,d1 instructions: 3 code size: 6 registers used: 3 B: move.l a0,d0 and.l #1,d0 instructions: 2 code size: 8 (6 bytes with my immediate compression enhancement) registers used: 2 C: moveq #1,d0 and.l a0,d0 instructions: 2 code size: 4 registers used: 2 Code A above is the most optimal and best code density for most 68k CPUs but needs an extra instruction, 2 trash registers and is not easy for compilers to generate. Code B is easier for compilers to generate but gives poor code density. Code C is the most compact and is not difficult for compilers. Simpler and shorter looks better to me and *not* ugly.

My earlier design could execute it in theory (as it was never finished) as integer units could read address registers but I still think it ugly. It starts changing the uses of A registers while not being too useful in itself.

Yes it would open up the use of A registers for semi-constant values but the initialization of the registers would still be over the D-A split, not orthogonal by design. It would require new code so there is no inherent advantage over a normal register extension in compatibility, there would be a size advantage though (compared to using a prefix) and maybe that's enough.¨

But if the size advantage is the main point why not simply map the new data registers to the address sources? That would still be ugly of course and it would still be a special case.

I like the B version with your imm.w extension the best BTW.

Quote:

I documented addressing mode sources being opened in the old 68kF pdf docs (yellow highlighting for new enhancements). http://eab.abime.net/showthread.php?t=83642 There is barely a noticeably difference unlike when I tried to open up address register destinations (a few encoding conflicts and different CC behavior). My new ISAs are called 68k_64 and 68k_32 with significant changes to allow for 64 bit support which I am still working on.

Address register as sources are much easier to support than address register destinations, in the design mentioned above that would mean increasing the size and capability of address generation units. That's also why I opposed your base register update, increments and decrements are easy to handle but updating from the EA can increase the latency of address register writes potentially decrease performance _and_ would require a more complicated AGU design.

Quote:

I wouldn't be so sure about that. Register renaming (like the 68060 uses) makes instruction scheduling easier without several data dependencies. The 68060 uses some good techniques to reduce load-use stall penalties like early instruction completion in the AG stage (EA calc) and instruction forwarding (the 68060 has pretty good performance with limited or no instruction scheduling common with poor 68k compiler support). The only real superscalar scheduling problem are true dependencies (sequential code), load-use stalls and one read, write or read/write DCache access per cycle. True dependencies can often not be removed, load-use stall penalties can be reduced and the DCache can be dual ported. Dual porting the DCache is expensive but it can turn CISC CPUs into memory munching monsters. The whole reg-mem operation can be scheduled along with register only operations which is very powerful. I think an in-order superscalar 68k with 3 integer pipes and dual ported DCache would outperform many 4 wide superscalar RISC CPUs with OoO. A good instruction scheduler would be necessary for maximum performance but I expect it would perform better than any 68k CPU on existing code as well.

You are talking about a mid-90's design when the optimal design point was completely different compared to now, even if implemented in (relatively) slow FPGAs. In fact having to use FPGAs shifts the optimal design point even further from the 68060, Pentium and (more comparable with the 68060) the Cyrix 6x86 type design.

For high performance in a FPGA the pipeline will have to be deeper than in an ASIC, there is a paper comparing ASIC and FPGA design that makes that clear (will try to find it later) and there are processor design papers that conclude an FPGA design have to fit the available hardware and be deeper than ASIC designs.

In the 68060 cache latency is low, 1 clock cycle. In a modern x86 it is about 4 cycles. In the 68060 decoding is fast, in modern designs it usually takes several stages even for RISC (not always apparent in pipeline descriptions as each stage does multiple things).

I would prefer a deeply pipelined scalar CISC with out of order execution as a design point for FPGA, just as I did many years ago. I'd just scaled down the emphasis of pushing the clock rate as high as possible of my earlier design. And yes I think it would be competitive with your in-order design as it would clock higher and could tolerate cache misses and cache latency much better.

Quote:

The 68k should be closer to the CISC AMD64 in register usage than RISC although it is more efficient in memory (68k is a reg-mem mem-mem hybrid with more powerful addressing modes where x86 is a reg-mem accumulator hybrid). One important consideration is the penalty when out of registers. ... It is RISC that has problems with load-use stalls after loads. Quote: APOLLO 68080 can do a free DCache read per cycle So technically instead loading values in advance in register you can also just do this: FMUL.S (a0),Fp0 FMUL.S 4(a0),Fp1 FMUL.S 8(a0),Fp2 You can read in every instruction from Cache, even if you re-read the same value, this is no disadvantage. With a single fp unit, there is no slowdown with the code above. With a dual ported DCache and 2 fp units, there is no slowdown. If we can schedule a memory access instruction with a non memory access instruction then there is no slowdown. Why does the 68k need so many registers?

(I've compacted this series of quotes as they are about the same thing)

No the load-use is a problem for all processors and no, the CISC have no advantage other than the code size. The same operations have to be done, the same dependencies have to be solved and the same physical access to caches have to be executed.

A simple in-order CISC processor can inline the cache fetch. It doesn't mean the address generation isn't there as in a RISC, it doesn't mean the cache latency isn't there and it doesn't solve any dependency problems. In-order RISC can do the equivalent by skewing the execution pipeline so that the data cache results can be delivered to the execution stage of the dependent instruction - like in the POWER6 processor.
One potential advantage would be removing one dependency check for a load-op instruction. In practice the check still have to be there for any reasonable design.

The chain of FMUL instructions aren't illustrating anything interesting other than misdirection: it simply isn't relevant. Yes if one have a two wide scalar processor with two memory ports one can do two memory operations per clock assuming a cache hit. And yes a RISC would need four instructions to do the same thing. But the operation latency would be the same as the same thing is done.

Now the reality is that the Apollo core according to the (bad) documentation available can't actually do two memory operations per clock. So we should be comparing a superscalar inline RISC with the above. Per clock it could do one memory load and one FP multiplication. Same performance - with lower code density.

And why does the 68k need so many registers? Because reality is what it is. We don't have a zero latency address generator, we don't have a zero latency cache and we don't have free multi-ported cache. Registers are much cheaper to access, multi-porting register files aren't cheap or free but it still have to be done. With Xilinx FPGA the register file is 64 entry for free, with Intel FPGA 32 entries are free IIRC. That means using fewer registers is wasting resources while using more requires extra effort.

Quote:

Quote: The PPC MMU is... interesting. The 68060 is more of a standard design. Which one, the old AIM or new Book E version?

I have only read old documents and it was a while ago... 15 years or so?

Quote:

That's the problem. It would be nice to have and MMU which is still able to run Linux and BSD.

Exactly :)
There are good reasons there aren't many truely innovative designs in computing anymore, have to keep running old code directly or at least be compatible enough to just require recompilation and minor tweaks to the OS.
For a modern 68k I'd use the 68060 MMU as the base.

Quote:

Speculative execution may be on the decline with Spectre.

Not possible. The reason computing performance have increased is due to speculation, the important improvement of OoO execution isn't instruction reordering itself but providing support for speculative execution.
There are two problems to solve: increase isolation between protection domains and decrease information leakage. Both are possible to do with much less performance impact than that of removing speculative execution.

Quote:

Crossing over to supervisor mode still has many times the overhead of a subroutine on the user side. This is significantly cheaper than an interrupt/exception like a timer interrupted context switch. Both are performance concerns for a micro-kernel even as they have become cheaper on modern hardware.

An exception needn't take much more time than a pipeline flush like after a mispredicted branch. Switching to supervisor mode needn't take more than a few clocks.

Most hardware isn't optimized for such things but still one can look at the Itanium abomination that IIRC had a syscall cost of 30 cycles in a L4 kernel.

@cdimauro
Quote:

@megol Quote: Quote: With the CISC I think you mean the availability of memory operands? That isn't really an advantage anymore, at least looking at a reasonably modern core. One can see such operations a code density advantage however the increasing load-use latency dictated by physics makes them a performance problem. I don't see it. I think that this is still one of the biggest CISC advantages, which not only increases code density but also allows to save a register and avoid instruction dependencies, with overall benefits on performances too. IMO this is quite evident on processor designs which aren't out-of-order.

Ah here we have the "problem": I'm assuming an OoO 68k processor implemented in FPGA, not a in-order short pipelined core like the Apollo or 68060. Yes for a simple design there are advantages however as soon as one goes OoO the disadvantage disappears as the loaded data can't just be forwarded to a waiting execution stage. It either have to be buffered in a register or in some other resource e.g. a stateful ROB.

If a two pipeline in order design with inline memory loads stall on a cache miss both pipelines reasonably stall, the best case would be with a cache supporting hit-under-miss handling however even then the pipe that can continue still have to stall before writeback.
That can be helped somewhat by supporting out of order retire of instructions, if so the second pipeline can not only execute but also write the result if dependencies allow that. But then what? Should the second pipeline be permitted to decode the next instruction? Then we have a complicated low performance out of order processor.

Even in the best case and all the expensive special casing required a cache miss will soon make the whole processor stall. So one better have a good L2 cache with good prefetchers.
--
I wonder if the added out of order support of the Apollo is actually out of order retire of FPU instructions?

@Barana
Quote:

Barana wrote: @cdimauro I note with thanks your cordiality to me in your previous response. I ask you extend the same cordiality to Gunnar, who Is a genuine amigan - used to hang out quite a bit before you joined aw.net and made friends with many of us. He and his team who haven't finished yet, have talent I only dream of. Unless,of course you'd like to produce today for us an 080 core that rivals or betters his? Again,, thankyou for the cordiality you showed me today,Could we throw some Gunnar's way? An industrious Amigan?

I think we are all more than generous towards Gunnar. But we have seen the truth and the truth is what it is.

Quote:

megol wrote: I think we are all more than generous towards Gunnar. But we have seen the truth and the truth is what it is.

He is delivering actual products rather than pontificating on a forum?

Last edited by gregthecanuck on 16-Sep-2018 at 03:43 PM.

@megol

Quote:

I think we are all more than generous towards Gunnar. But we have seen the truth and the truth is what it is.

I just had a quick read of the "we are going OoO" thread on the Apollo forum, and yes, my opinion of Gunnar has once again be reconfirmed.

The guy is either extremely clueless, or extremely dishonest. Or possibly both. But he most certainly isn't someone I would ever consider hiring.

Yes, someone in the team certainly knows what they are doing, as is evident from the results. I am very, very far from convinced that Gunnar is that someone.

The same was true back in the Natami days --- Thomas Hirsch really knew his shit, and did amazing work. Gunnar, on the other hand, produced an amazing amount of prose on technical subjects, a lot of which really didn't make much sense to anyone with a sufficiently technical background to assess it.

(No, I haven't designed a 68k core in FPGA. I do however write this post in the compiling downtime of a signal processing project which has about 220 clock cycles to do a fair amount of processing on two separate streams of data, with hard real time requirements. And that includes acquiring the data from the ADC, and pushing the results out on GPIOs. So yeah, I do know a thing or two about the actual execution speed, and performance traps, of processors.)

@gregthecanuck

Quote:

gregthecanuck wrote: Quote: megol wrote: I think we are all more than generous towards Gunnar. But we have seen the truth and the truth is what it is. He is delivering actual products rather than pontificating on a forum?

Is he? I credit Majsta for learning FPGA programming, circuit design, soldering and a lot more for the purpose of making FPGA accelerators for the Amiga. And he did. By himself.

I don't know how much of the Apollo is the work of Gunnar. He have shown in the past to have some basic misconceptions about processors and that is still occasionally showing.

I credit him for being part of the Apollo project and there have no claims or implications from me that he did not do real work in making the Apollo. Nor from anybody else what I've seen.

But claiming that Gunnar delivers products when I know that the FPGA accelerator design came from Majsta from the beginning is insulting not only to Majsta but to all of us that knows that Gunnar didn't do this by himself!

@megol

Quote:

accelerator design came from Majsta

igors accels have used a variant of tobiflex core (the only effectively available open m68k compatible fpga option) before. it was magnitudes slower, so even though none diminishes igors engagement, competence, whatever/you call it, on the contrary, igos says the same, there is a fair amount of achievement on part of "apollo team", gunnar or whoever chooses to hide behind his nick, in order to work in peace not affected of a forum flak. to me it it is an "all the same" blackbox.

Last edited by wawa on 16-Sep-2018 at 04:18 PM.

@Barana

Quote:

Barana wrote: If they are not released yet, it will only give you more time to save.

So I should be thankful for every product that's not available?

Since Commodore went bankrupt we all got a lot of time for saving money.