Amiga.org
Amiga computer related discussion => Amiga/MorphOS/AROS Programmers Forum => Topic started by: ferrellsl on June 22, 2017, 05:37:02 PM
-
http://www.apollo-core.com/knowledge.php?b=1¬e=6668
-
Software taking benefit from this is developed at the time being.
This is hilarious.
-
This is hilarious.
That's no more hilarious than having multi-core PPC CPU's to run OS4. How many years ago has it been that OS4 users were promised SMP? Roughly 10 years if my memory serves me correctly. AROS x86 has made great strides of late as far as SMP goes, so I expect hyper-threading support to make its way into the 68K version soon.
-
With the Gunnar, Amiga 68k is becoming more and more like OS4 - first an incompatible "tabor A1222" like modern FPU, and now multithreading and need for SMP... oh, I forgot AMMX... "Amivec" is next.
-
AROS x86 has made great strides of late as far as SMP goes, so I expect hyper-threading support to make its way into the 68K version soon.
Hmm, quite sure it was the Raspberry Pi 3 with its quad core that ignited the SMP work in AROS, so not x86, but ARM. Anyways, the AROS developers have said quite explicitly that there will not be any SMP support for AROS/m68k. So, how this hyperthreading will be utilized by Amiga products is not easy to guess.
Also, the news is that Apollo Core will have hyperthreading, not that the core running on Vampires will have it - those are two separate products, remember? The Amiga vampire platform is merely guinea pigs for the real product, which is the Apollo core.
-
Hmm, quite sure it was the Raspberry Pi 3 with its quad core that ignited the SMP work in AROS, so not x86, but ARM. Anyways, the AROS developers have said quite explicitly that there will not be any SMP support for AROS/m68k. So, how this hyperthreading will be utilized by Amiga products is not easy to guess.
Also, the news is that Apollo Core will have hyperthreading, not that the core running on Vampires will have it - those are two separate products, remember? The Amiga vampire platform is merely guinea pigs for the real product, which is the Apollo core.
It doesn't matter what ignited it. But of late, the progress with AROS SMP has been with the x86_64 version which I test on a regular basis and it works quite well.
Clearly Gunnar's announcement implies that the Vampire will support hyper-threading since the Vampire uses the Apollo core and not some other core.
But all of this remains to be seen. At least there are some interesting things going on with regard to 68K development.
-
That's no more hilarious than having multi-core PPC CPU's to run OS4. How many years ago has it been that OS4 users were promised SMP? Roughly 10 years if my memory serves me correctly. AROS x86 has made great strides of late as far as SMP goes, so I expect hyper-threading support to make its way into the 68K version soon.
I'd actually agree with you here, its not at all hilarious.
There is absolutely no reason what so ever that 68K software could not advance toward the use of SMP.
And the features being incorporated into the Apollo core will offer much of the utility that is missing from older cpus like the 68K family.
If legacy compatibility can be retained, while modernizing the processor, I'm all for it.
Given the slow progression of OS4, if that community isn't careful, it may find that the legacy community has caught up to them by the time they are ready to release OS4.2.
Now THAT would be hilarious. 68K continuing to be developed, while PPC go by the wayside. And instead of OS4.2 or OS5, AROS becomes the platform of choice for Amigans.
It COULD happen, so I for one, thank Steven for making the post.
-
That's no more hilarious than having multi-core PPC CPU's to run OS4. How many years ago has it been that OS4 users were promised SMP? Roughly 10 years if my memory serves me correctly. AROS x86 has made great strides of late as far as SMP goes, so I expect hyper-threading support to make its way into the 68K version soon.
I just think it's hilarious that "Software for this is coming!" vs software already written for a known quantity (FPU), and him saying "Ohhh there's nothing important that uses the FPU" despite 3d artists, and people who like to play 3d games like Quake and variants. That's the funny part, to me :D
-
I just think it's hilarious that "Software for this is coming!" vs software already written for a known quantity (FPU), and him saying "Ohhh there's nothing important that uses the FPU" despite 3d artists, and people who like to play 3d games like Quake and variants. That's the funny part, to me :D
I don't ever remember Steven suggesting an fpu didn't have utility, although many others have.
One thing many of you forget is he DOES actually know quite a bit about computing (six years of education...he damned well better), SO...any disagreements I may have had with the man aside, I do agree with him on this.
Hyperthreading DOES sound useful.
-
I don't ever remember Steven suggesting an fpu didn't have utility, although many others have.
One thing many of you forget is he DOES actually know quite a bit about computing (six years of education...he damned well better), SO...any disagreements I may have had with the man aside, I do agree with him on this.
Hyperthreading DOES sound useful.
Oh I don't think he's not smart or anything of the kind! I just find it lulzworthy, that's all. No real utility for FPU (rendering packages and games that use it already exist) vs. Hyperthreading!...for which there is no (current!) use. It's like...dude make up your mind XD
-
Wow, it is great, it seems they are strictly following their own roadmap.
I hope they build a fully integrated 4 bit ALU as a next feature, or complete PDP opcode implementation.
-
wow, it is great, it seems they are strictly following their own roadmap.
I hope they build a fully integrated 4 bit alu as a next feature, or complete pdp opcode implementation.
f'in LOL
:D :D
-
This Gunnar is like GOD. He makes miracles, we want to believe in him & keep the faith, but nobody has seen him.
-
Majority of Amiga's softaware has been made 1985 -2000, nothing will change that.
So most important feature of Apollo core is compatibility to previous CPUs.
So, for my point of view they are going to wrong direction.
Anyway this is their hobby Project so they do what tehy want to do. Some reason they are not interested to FPU, wich is disspoints me, but I have my 68060 acceleratos, so I can live with it.
Just got my Apollo 68040 upgraded to 68060. :)
-
This Gunnar is like GOD. He makes miracles, we want to believe in him & keep the faith, but nobody has seen him.
Ahem...
(http://www.greyhound-data.com/gunnar/gunnar.jpg)
http://www.greyhound-data.com/gunnar/gunnar.jpg
Not hard to find images of Gunnar "Big Gun" Von Boehn, you can keep your faith, but a God...no.
-
I love the direction in which the Apollo Team is heading.
Bring it on, bring it on, bring it on.
-
I love this direction too:
I hope he now adds yet another cpu register so that it allows me to change the background of a guru screen when running.
-
Food for thought:
-Identify at least four methods how to disable multitasking on AmigaOs.
-What is the value of ExecBase->ThisTask on an SMP system?
-Design a minimal non-locking critical region on AmigaOs.
-What is the purpose of a blue screen on windows? (Hint: Windows supports SMP).
-
Food for thought:
-What is the value of ExecBase->ThisTask on an SMP system?
at least for this one you can refer to aros sources for example. im not sure though if it has any relevance in this context.
-
Some of you may not have noticed the update: "Our team has several drivers and libraries in development.
Drivers like NETWORK, WIFI, SDCard, IDE, RTG Graphics....
These drivers which we develop can utilize and benefit from Hyper-threading already today - even without OS support for SMP.
Using Hyperthreading on such drivers lowers latency, improves thoughput (faster IDE/ faster Internet), and improves the snappiness of the whole system."
-
"can", "may", "maybe"
So Gunnar passes on big hopes for AROS despite...
http://www.apollo-core.com/knowledge.php?b=4¬e=6171&z=UfZpZv
Kalamatee (AROS)
Posts 12
05 Jun 2017 18:28
Sorry to be the bearer of bad news - but there won't be support for smp in the m68k build ever. The m68k platform has no provision for working in an smp-like environment, and changes would make it binary incomparable with existing amigaos/aros for m68k.
If the vampire/apollo team create some "smp like" m68k core, it would need its own custom m68k flavour of aros, and most m68k apps won't work on it.
-
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.
-
So essentially it's like putting a toilet in your kitchen and calling it a 'feature'?
-
So essentially it's like putting a toilet in your kitchen and calling it a 'feature'?
Well.... I would rather say it's more like attaching a power drill to a toothbrush, but except that... Yes, it could potentially be useful in the future somehow, but there features that I would consider more important, that have been delayed for quite a while, and that would provide more benefit. Just that they would require more work to implement and have larger design implications.
-
Like WarpUp or PowerUp, only with something 68k-ish instead of PowerPC.
-
There used to be a few multi-processor 68k unix stations back in the days, if I recall correctly. About the same time Amiga users were drewling over the prospect of having transputer cards, lol... how things go around in circles :)
-
About two decades ago, for a few weeks I worked as a junior in what was the IT department of a now defunct bank.
I clearly remember they had a dual 68010 unix like server. I was amazed by it.
Cant remember the brandname/model of the machine :(.
-
Does anyone remember this.
(http://rodolphe.czuba.free.fr/Phenix/photo_moy.jpg)
-
Does anyone remember this?
Never saw this before, but its beautiful.
Dual '060s and a PCI bus.
Now imagine a similar board with Apollo cored FPGAs in place of the '060s.
Better yet, PCIe expansion slots instead of the PCI slots...
A second group of custom slots for four to eight FPGA boards...
68K systems capable of eight to sixteen concurrent threads?
SO...could we compete with modern hardware with THAT?
-
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.
-
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.
-
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.
-
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. :)
-
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.
-
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?
-
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.
-
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.
-
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.
-
@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.
-
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 ;)
-
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 ;)
-
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.
-
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.
-
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.
-
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.
-
Now, what does your interrupt do that it requires less than 30 cycles in actual payload code?
The interrupt might just signal or enqueue, which should be quite low number of cycles. But maybe the movem.l is dumb and stalls the pipeline until it's written all the registers.
-
The interrupt might just signal or enqueue, which should be quite low number of cycles. But maybe the movem.l is dumb and stalls the pipeline until it's written all the registers.
Even if it's just a "AddTail()" and "Signal()", that's more than 30 cycles. If you have a second core, you cannot - of course - use Signal() or enqueue either. The exec synchronization primitives are for a single core only.
-
I don't doubt that there are limitations of apollo and working round it with hyperthreading is probably easier for him.
Read-ports are a limitation of all CPUs. What's the highest read-port count in a CPU you know of?