Welcome, Guest. Please login or register.

Author Topic: APOLLO 68080 is now HYPER-THREADING enabled  (Read 13130 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Crom00

  • Hero Member
  • *****
  • Join Date: Nov 2005
  • Posts: 1234
    • Show only replies by Crom00
Re: APOLLO 68080 is now HYPER-THREADING enabled
« Reply #29 from previous page: June 23, 2017, 07:33:59 PM »
Quote from:
SO...could we compete with modern hardware with THAT?[/QUOTE

Heh... don't give them any more CrAzY ideas. I was on IRC in Dev channel and BigGUN mentioned that including the HT option was easy for him to do since it takes up about 400 gates compared to and FPU that takes up tens of thousands of gates and dev time to perfect.

I don't remember if "gates" was the correct term, but FPGA's have a certain capacity depending on the model. Some sort of term is used to identify the amount of circuitry you can create on an FPGA.

I do some graphics over there, not a hardware or CPU designer, not qualified to get super technical on the matter.
 

Offline Iggy

  • Hero Member
  • *****
  • Join Date: Aug 2009
  • Posts: 5348
    • Show only replies by Iggy
Re: APOLLO 68080 is now HYPER-THREADING enabled
« Reply #30 on: June 23, 2017, 08:22:48 PM »
Quote from: Crom00;827497
Heh... don't give them any more CrAzY ideas. I was on IRC in Dev channel and BigGUN mentioned that including the HT option was easy for him to do since it takes up about 400 gates compared to and FPU that takes up tens of thousands of gates and dev time to perfect.

I don't remember if "gates" was the correct term, but FPGA's have a certain capacity depending on the model. Some sort of term is used to identify the amount of circuitry you can create on an FPGA.

I do some graphics over there, not a hardware or CPU designer, not qualified to get super technical on the matter.


I suppose it would depend on how modern you wanted it to be.
But even just the original Phenix board itself would be significantly less painful to web browse with than a legacy Amiga.

With even faster cpus (or even more of them), better still.
"Not making any hard and fast rules means that the moderators can use their good judgment in moderation, and we think the results speak for themselves." - Amiga.org, terms of service

"You, got to stem the evil tide, and keep it on the the inside" - Rogers Waters

"God was never on your side" - Lemmy

Amiga! "Our appeal has become more selective"
 

Offline Rob

APOLLO 68080 is now HYPER-THREADING enabled
« Reply #31 on: June 24, 2017, 12:34:45 AM »
Quote from: Iggy;827496
Never saw this before, but its beautiful.
Dual '060s and a PCI bus.


I remembered it from a little piece from the new section of one of my magazines, I think it must have been Amiga Format.  I had a fair idea it never happened in the end but never really gave it much though until this thread.  It's unusual that the manufacturers site is still there after this time.
 

Offline Terminills

  • Grand Conspirator
  • Hero Member
  • *****
  • Join Date: Jan 2003
  • Posts: 588
  • Country: 00
  • Thanked: 2 times
    • Show only replies by Terminills
Re: APOLLO 68080 is now HYPER-THREADING enabled
« Reply #32 on: June 24, 2017, 11:29:07 AM »
Quote from: Thomas Richter;827486
Actually, that's not quite true. The 68K has as many provisions for multiprocessing as every other CPU, namely the necessary synchronization primitives TAS and CAS (and some members even CAS2), plus cache-snooping. Thus, as far as the 68K series is concerned, there is no show-stopper.

There is a practical show-stopper against SMP, and that's AmigaOs, and the Amiga hardware, which - natively - does not support CAS and TAS. As long as a program runs in local memory (not on Zorro, not on chipmem), and only assymetric multiprocessing is concerned, this is a possibility. Any additional core (wether virtual or real) is then bound to run helper tasks beyond the exec scheduler.

That's possible, though that is as much multiprocessing as the Copper is multiprocessing as well. It's just a more complex second processor that speaks, by chance, 68K machine code and not copper machine code.

None of that will give you multicore multitasking in AmigaOs. The Os is a toy-system with the wrong Os primitives.



I think kalamatee was talking about the AROS 68K platform not 68K in general. :)
Support AROS sponsor a developer.

edited by mod: this has been addressed
 

Offline Thorham

  • Hero Member
  • *****
  • Join Date: Oct 2009
  • Posts: 1149
    • Show only replies by Thorham
Re: APOLLO 68080 is now HYPER-THREADING enabled
« Reply #33 on: June 24, 2017, 01:09:15 PM »
Quote from: Iggy;827496
SO...could we compete with modern hardware with THAT?
To compete with current peecee hardware, the first thing you need is for 68k to run at speeds similar to current peecee CPUs. While technically not impossible, of course, I don't think any affordable FPGAs are going to give you that kind of performance.
 

Offline kolla

Re: APOLLO 68080 is now HYPER-THREADING enabled
« Reply #34 on: June 25, 2017, 03:41:28 PM »
Quote from: ferrellsl;827452
Clearly Gunnar's announcement implies that the Vampire will support hyper-threading since the Vampire uses the Apollo core and not some other core.

It uses a dedicated subset of the Apollo Core, specialized for the Vampire V2 cards. Just like Phoenix was an even smaller subset, for the V1. Or else there would be an FPU (which the full core has), and binary compatibility with ColdFire and whatever else the "full" core offers.

How many times have we been told to not mix what the Apollo Core offers with what the Vampire offers? And still people talk of them as they were one and the same? Why is that?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline ferrellslTopic starter

  • DavidseltyAJ
  • Hero Member
  • *****
  • Join Date: Jan 2005
  • Posts: 868
  • Country: ph
  • Thanked: 2 times
  • Gender: Male
    • Show only replies by ferrellsl
Re: APOLLO 68080 is now HYPER-THREADING enabled
« Reply #35 on: June 25, 2017, 04:43:18 PM »
Quote from: kolla;827574
It uses a dedicated subset of the Apollo Core, specialized for the Vampire V2 cards. Just like Phoenix was an even smaller subset, for the V1. Or else there would be an FPU (which the full core has), and binary compatibility with ColdFire and whatever else the "full" core offers.

How many times have we been told to not mix what the Apollo Core offers with what the Vampire offers? And still people talk of them as they were one and the same? Why is that?


I'm not confusing anything.  Maybe you should actually go and read Gunnar's posts about how hyper-threading will be used in the Vampire instead of speculating about it in a vacuum.  The only one here who seems to be confusing things is you.  I even put the link to his comments in my first post but you seem to be too obstinate to even check it out.

Offline Djole

  • Sr. Member
  • ****
  • Join Date: Nov 2012
  • Posts: 252
    • Show only replies by Djole
Re: APOLLO 68080 is now HYPER-THREADING enabled
« Reply #36 on: June 25, 2017, 04:58:27 PM »
Quote from: kolla;827574
It uses a dedicated subset of the Apollo Core, specialized for the Vampire V2 cards. Just like Phoenix was an even smaller subset, for the V1. Or else there would be an FPU (which the full core has), and binary compatibility with ColdFire and whatever else the "full" core offers.

How many times have we been told to not mix what the Apollo Core offers with what the Vampire offers? And still people talk of them as they were one and the same? Why is that?


You are right Kolla, this time. HP is (or will be) the part of Vampire Apollo core (not public yet). Like for some other features there is no or little sw support. Gunnar did explain on the Apollo forum how to make use of HP on AmigaOS for some real speedup. We will see if something will come from this.
A1200 030
A1200 stock
A600 Vampire v2

VOLIM TE REPUBLIKO SRPSKA!
[/B][/COLOR]
 

Offline wawrzon

Re: APOLLO 68080 is now HYPER-THREADING enabled
« Reply #37 on: June 25, 2017, 05:15:53 PM »
Quote from: kolla;827574

How many times...


you could actually boot these debug roms i sent you instead just posting once on the forums. that might actually contribute a bit to your platform of choice.
 

Offline kolla

Re: APOLLO 68080 is now HYPER-THREADING enabled
« Reply #38 on: June 25, 2017, 05:17:35 PM »
@djole
Exactly.

I can't help being amused by how Gunnar is now "herding the cats" over at his forum, where... ehm... enthusiastic suppoerters... spin the speculations wheel wild. I am glad he is doing something about that now, and I bet he almost regret his announcement, lol.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline kolla

Re: APOLLO 68080 is now HYPER-THREADING enabled
« Reply #39 on: June 25, 2017, 05:23:48 PM »
Quote from: wawrzon;827578
you could actually boot these debug roms i sent you instead just posting once on the forums. that might actually contribute a bit to your platform of choice.


I am mostly posting from my phone, right now from a train passing through the highlands of Jämtland, on my way home. I did not bring the MIST on this weekend's cabintrip, sorry. I did try to boot them a few times before I left though, but instead of booting into AROS, it ended in just rebooting, with the regular kickstart. I will spend more time on it when I get home in a few hours, no worries ;)
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline wawrzon

Re: APOLLO 68080 is now HYPER-THREADING enabled
« Reply #40 on: June 26, 2017, 09:48:33 AM »
Quote from: kolla;827580
I am mostly posting from my phone, right now from a train passing through the highlands of Jämtland, on my way home. I did not bring the MIST on this weekend's cabintrip, sorry. I did try to boot them a few times before I left though, but instead of booting into AROS, it ended in just rebooting, with the regular kickstart. I will spend more time on it when I get home in a few hours, no worries ;)


thx for the log ;)
 

Offline psxphill

Re: APOLLO 68080 is now HYPER-THREADING enabled
« Reply #41 on: June 27, 2017, 11:07:32 AM »
Quote from: Djole;827577
Gunnar did explain on the Apollo forum how to make use of HP on AmigaOS for some real speedup.


I read his post and he suggested using one register set for user mode and one for interrupt mode, purely to avoid the movem.l overhead when processing interrupts & not actually run code using the two register sets simultaneously.

It should be possible to make movem.l into cached ram pretty instantaneous though. Which would benefit calling ever single function.
 

Offline grond

  • Full Member
  • ***
  • Join Date: Feb 2016
  • Posts: 154
    • Show only replies by grond
Re: APOLLO 68080 is now HYPER-THREADING enabled
« Reply #42 on: June 27, 2017, 11:29:10 AM »
Quote from: psxphill;827657
I read his post and he suggested using one register set for user mode and one for interrupt mode, purely to avoid the movem.l overhead when processing interrupts and not actually run code using the two register sets simultaneously.

It should be possible to make movem.l into cached ram pretty instantaneous though. Which would benefit calling ever single function.

The 080 HT allows running two threads at the same time but AmigaOS does not. Hence the idea of off-loading IO tasks (i.e. device drivers) to the second hardware thread.

movem.l is a more difficult instruction to speed up than you believe. It is a multi-cycle instruction like DIV and thus runs only on one of the two pipelines. Furthermore it needs to read up to 15 registers when the register file is limited to only two read-ports per pipeline.

AFAIK in the 080 a movem takes one cycle per register to be moved. A context switch needs to save and load even more data from registers (stack pointer, status), each on entry and exit. If you have interrupt driven IO (e.g. disk, network), you can easily have thousands of interrupts per second and the interrupt mechanism becomes very costly. Using the HT for device handling is a simple way of removing this overhead. Of course, a multi-CPU AmigaOS would be even better but that won't happen easily.
 

Offline psxphill

Re: APOLLO 68080 is now HYPER-THREADING enabled
« Reply #43 on: June 27, 2017, 04:31:47 PM »
Quote from: grond;827659
movem.l is a more difficult instruction to speed up than you believe. It is a multi-cycle instruction like DIV and thus runs only on one of the two pipelines. Furthermore it needs to read up to 15 registers when the register file is limited to only two read-ports per pipeline.


I don't doubt that there are limitations of apollo and working round it with hyperthreading is probably easier for him.
 

guest11527

  • Guest
Re: APOLLO 68080 is now HYPER-THREADING enabled
« Reply #44 on: June 27, 2017, 08:06:42 PM »
Quote from: psxphill;827657
I read his post and he suggested using one register set for user mode and one for interrupt mode, purely to avoid the movem.l overhead when processing interrupts & not actually run code using the two register sets simultaneously.
Quite frankly, what does your interrupt process that you need to worry about movem? If that's one cycle per instruction, and you save at most 15 registers, then that's 30 cycles maximum for the movem. Now, what does your interrupt do that it requires less than 30 cycles in actual payload code?

Remember, we're talking here about a 100MHz CPU. Not a 1.79Mhz 6502 which, I admit, did run into such problems.