Poster | Thread |
kolla
|  |
Re: News about Vampire and Apollo Posted on 18-Nov-2017 2:10:47
| | [ #1421 ] |
|
|
 |
Elite Member  |
Joined: 20-Aug-2003 Posts: 3353
From: Trondheim, Norway | | |
|
| @simplex
Except this is AmigaOS and normal terms don't apply. In principle any task could tell the cpu to go hyperthreaded and make use of the threads, though it would make more sense to leave it to a dedicated scheduler. This is not much different from how WarpUP or PowerUP works, except there is no need for ppc code or cache flushing. _________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
|
Status: Offline |
|
|
simplex
|  |
Re: News about Vampire and Apollo Posted on 18-Nov-2017 5:23:36
| | [ #1422 ] |
|
|
 |
Cult Member  |
Joined: 5-Oct-2003 Posts: 896
From: Hattiesburg, MS | | |
|
| @kolla
Quote:
Except this is AmigaOS and normal terms don't apply. |
Reread retro's quote, especially in context of what bennymee was saying, before reading my reply:
I don't disagree with you, but (a) your suggestion effectively makes AmigaOS aware of multiple processors (they're just "logical" as opposed to "physical"), and (b) retro stated, "the amiga os wouldn't know." Well, yes, it would, just as the point of WarpUP and PowerUP make AmigaOS aware of another processor._________________ I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me. |
|
Status: Offline |
|
|
simplex
|  |
Re: News about Vampire and Apollo Posted on 18-Nov-2017 6:26:19
| | [ #1423 ] |
|
|
 |
Cult Member  |
Joined: 5-Oct-2003 Posts: 896
From: Hattiesburg, MS | | |
|
| @kolla
Quote:
In principle any task could tell the cpu to go hyperthreaded and make use of the threads... |
BTW, I'm reasonably sure this will not work in general, when you start monkeying around with system resources that are not parallel-aware, such as memory allocation (as just one example). The OS itself would need new locks around a lot of things. Not quite the same as what you have with PowerUP and WarpOS._________________ I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me. |
|
Status: Offline |
|
|
Samurai_Crow
|  |
Re: News about Vampire and Apollo Posted on 18-Nov-2017 9:13:27
| | [ #1424 ] |
|
|
 |
Elite Member  |
Joined: 18-Jan-2003 Posts: 2320
From: Minnesota, USA | | |
|
| regarding hyperthreading: I think the easy way to implement added threads is to use a job queue like QBlit does in Graphics.library. It's not symmetric but it's completely parallel. If the jobs are independent of one another, more threads can be added in parallel. |
|
Status: Offline |
|
|
Overflow
 |  |
Re: News about Vampire and Apollo Posted on 18-Nov-2017 21:06:40
| | [ #1425 ] |
|
|
 |
Super Member  |
Joined: 12-Jun-2012 Posts: 1628
From: Norway | | |
|
| |
Status: Offline |
|
|
kolla
|  |
Re: News about Vampire and Apollo Posted on 19-Nov-2017 6:46:44
| | [ #1426 ] |
|
|
 |
Elite Member  |
Joined: 20-Aug-2003 Posts: 3353
From: Trondheim, Norway | | |
|
| @simplex
Quote:
simplex wrote: @kolla
Quote:
In principle any task could tell the cpu to go hyperthreaded and make use of the threads... |
BTW, I'm reasonably sure this will not work in general, when you start monkeying around with system resources that are not parallel-aware, such as memory allocation (as just one example). The OS itself would need new locks around a lot of things. |
Of course it will not work in general, it requires dedicated support in whatever software that will use it.
So, let's speculate... a task asks exec to allocate some address range, and is given a range which it allocates. Then it tells CPU to go hyperthreaded and sends off the second thread (the one not currently running the OS) on a mission on its own, passing along the address range for where it expects to see results. While the "main thread" (the one that the OS is aware of) is doing something mundane, the second thread is operating outside of the OS, and when done, it writes the resulting data at the targeted memory address range, gives the "main thread" a little wink before exiting, and the main thread can turn off hyperthreading.
Of course, having many pieces of sotware wanting to hyperthreading at once, it's probably best that "that other thread" has a scheduler on its own.
Memory allocation? You are aware that the Apollo Core has its own MMU and can bounce around the Amiga memory address space at its own heart will? Not all the memory is even given to AmigaOS in the first place. So, in the silly example above, the spin off task would not even have to write its results to the physical location where the "main thread" (or anyone else) expects to find it, it could just tell the 68080 MMU to map the requested address range of AmigaOS to the physical address range where the wanted results are.
Imagine a simple memcopy from one address range to another address range in AmigaOS - the Apollo Core can catch that a memcopy is going on and just map the address space of the target range to the same address range as the original data - woopdidoo, tens of MB of data instantly "copied". You make changes in the targeted memory space? Sure, the MMU can let you write changes to a delta, and map addresses accordingly. Or the core can on its own accord tell the core to go hyperthreaded and tell the second core to actually perform a physical memcopy, if that is somehow desired, without the OS having _any_ idea about it.
Imagine legacy software writing to chipmem addresses, and magically that same data is available from certain fastmem addresses and vice versa. The 68080 MMU can do this and more.
The main point here is - what we like to call the operating system is no longer running the show, Apollo Core is - that is, the 68080 CPU, the 68080 MMU, and the firmware that clues it all together (sure, SAGA too). AmigaOS (and Amiga software) only gets to tap into "the fun" using dedicated (limited) interfaces available via resources and libraries.Last edited by kolla on 19-Nov-2017 at 06:53 AM. Last edited by kolla on 19-Nov-2017 at 06:50 AM. Last edited by kolla on 19-Nov-2017 at 06:48 AM.
_________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
|
Status: Offline |
|
|
Overflow
 |  |
Re: News about Vampire and Apollo Posted on 19-Nov-2017 11:22:11
| | [ #1427 ] |
|
|
 |
Super Member  |
Joined: 12-Jun-2012 Posts: 1628
From: Norway | | |
|
| |
Status: Offline |
|
|
simplex
|  |
Re: News about Vampire and Apollo Posted on 19-Nov-2017 12:27:24
| | [ #1428 ] |
|
|
 |
Cult Member  |
Joined: 5-Oct-2003 Posts: 896
From: Hattiesburg, MS | | |
|
| @kolla
You're arguing against a straw man here. I'm not saying it can't be done. What I'm saying is that (a) it's highly non-trivial and (b) hyper threading is practically equivalent to multiple cores, which is the original point anyway. (The criticism was that effort on multiple cores was wasted when you could implement hyper threading and somehow trick the system into avoiding the problems with multiple cores.)
For an example of (a). You write, Quote:
Memory allocation? You are aware that the Apollo Core has its own MMU and can bounce around the Amiga memory address space at its own heart will? |
That's irrelevant to what I'm talking about. What I'm talking about is this:
When a program allocates memory, malloc() or whatever requests it from the OS. (I'm referring to allocation so memcpy() does not enter into this question.) When this happens, the OS has to update various internal data structures. Suppose two parallel processes request memory from the OS at the same time; unless the OS is specially programmed for this, it will almost always trash memory. (I speak from some personal experience here.) The question of allocation in parallel has nothing at all to do with the MMU, and an MMU won't help avoid this problem.
I'm not sure how to illustrate (b) any more than I have, except to say that your "woopdidoo" scenario can be accomplished in exactly the same fashion using multiple cores, and probably much more safely since the separate cores would presumably have separate instruction and data caches, whereas hyper threading has documented problems with caching and thrashing.
Look, I'm not saying hyperthreading doesn't help; I'm not saying it's impossible; etc. I'm saying it's just as nontrivial for software as parallel programming is, so you might as well embrace the true deal._________________ I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me. |
|
Status: Offline |
|
|
Overflow
 |  |
Re: News about Vampire and Apollo Posted on 19-Nov-2017 19:00:49
| | [ #1429 ] |
|
|
 |
Super Member  |
Joined: 12-Jun-2012 Posts: 1628
From: Norway | | |
|
| The second link contains updated information in TXT format, with examples;
Quote:
GOLD 2.7 will come with AMMX2 instruction set. Please find here a preview of the AMMX Quickreference chart: www.apollo-core.com/AMMXQuickRef.pdf And a longer reference in TXT www.apollo-core.com/AMMX.doc.txt Please mind that the documentation is not final, AMMX2 includes a few more instructions for which documentation has to be written still.
|
|
|
Status: Offline |
|
|
amigakit
|  |
Re: News about Vampire and Apollo Posted on 29-Nov-2017 11:41:30
| | [ #1430 ] |
|
|
 |
Amiga Kit  |
Joined: 28-Jun-2004 Posts: 2638
From: www.amigakit.com | | |
|
| |
Status: Offline |
|
|
Overflow
 |  |
Re: News about Vampire and Apollo Posted on 11-Dec-2017 11:53:01
| | [ #1431 ] |
|
|
 |
Super Member  |
Joined: 12-Jun-2012 Posts: 1628
From: Norway | | |
|
| |
Status: Offline |
|
|
megol
|  |
Re: News about Vampire and Apollo Posted on 11-Dec-2017 12:53:55
| | [ #1432 ] |
|
|
 |
Regular Member  |
Joined: 17-Mar-2008 Posts: 355
From: Unknown | | |
|
| @Overflow
Gunnar doesn't seem to understand the concept of an MMU and how they have been used in the past. Now I know many Amiga people have/had misconceptions in the 90's but...
Having hardware address a physical address space and the processor(s) a virtual address space have been the standard. Having several memory controllers/spaces mapped into one common physical space have been standard. It works.
Todays systems tend to support virtual memory also for hardware devices (including DMA) using a IOMMU often external to the processor.
The existing 68060 MMU can be used in a modern system. The claims being made aren't true, direct compatibility is obviously possible. |
|
Status: Offline |
|
|
gregthecanuck
|  |
Re: News about Vampire and Apollo Posted on 12-Dec-2017 7:37:59
| | [ #1433 ] |
|
|
 |
Cult Member  |
Joined: 30-Dec-2003 Posts: 846
From: Vancouver, Canada | | |
|
| @megol
Quote:
Gunnar doesn't seem to understand the concept of an MMU and how they have been used in the past. Now I know many Amiga people have/had misconceptions in the 90's but...
Having hardware address a physical address space and the processor(s) a virtual address space have been the standard. Having several memory controllers/spaces mapped into one common physical space have been standard. It works.
Todays systems tend to support virtual memory also for hardware devices (including DMA) using a IOMMU often external to the processor.
The existing 68060 MMU can be used in a modern system. The claims being made aren't true, direct compatibility is obviously possible. |
It is my understanding that the Apollo core does indeed implement an IOMMU. I believe Gunnar mentioned that in IRC.
You need to give Gunnar some slack here. He has done design work on some major CPU platforms (Power, ARM). He knows what he is doing... coming up with a forward-looking design taking into account modern expectations of a processor.
Cheers!
|
|
Status: Offline |
|
|
OlafS25
|  |
Re: News about Vampire and Apollo Posted on 12-Dec-2017 9:47:23
| | [ #1434 ] |
|
|
 |
Elite Member  |
Joined: 12-May-2010 Posts: 6472
From: Unknown | | |
|
| @megol
you guys do not understand or not wanting to understand
MMU is not needed for most of the software, only for certain developer tools. They will offer replacements for these tools that use the MMU in 68080. You need MMU to run linux but linux is not on the plate and never was. Perhaps there will be a compatible MMU layer in future but that is not certain. Priority have other features including SAGA that is needed by most users and software. SAGA is also needed for the standalone device that already exists. So you guys expect just because a handful people want MMU to run 68k linux (what really makes no sense at all) that they delay the rest just to make you happy. And even if they did there would be still people moaning. I only say FPU. Last edited by OlafS25 on 12-Dec-2017 at 09:47 AM.
|
|
Status: Offline |
|
|
Overflow
 |  |
Re: News about Vampire and Apollo Posted on 12-Dec-2017 10:23:59
| | [ #1435 ] |
|
|
 |
Super Member  |
Joined: 12-Jun-2012 Posts: 1628
From: Norway | | |
|
| @OlafS25
Well, it comes back to "if you want something thats outside the teams roadmap, you need to offer contributions/accept workload yourself".
With regards to Linux, if this guy is for real;
http://www.apollo-core.com/knowledge.php?b=4¬e=11498
then there might some progress. If he is for real, and not a prank account, and have time to work on it, then he might be able to develop using the current Vampire MMU, instead of demanding legacy versions. |
|
Status: Offline |
|
|
OlafS25
|  |
Re: News about Vampire and Apollo Posted on 12-Dec-2017 14:15:34
| | [ #1436 ] |
|
|
 |
Elite Member  |
Joined: 12-May-2010 Posts: 6472
From: Unknown | | |
|
| @Overflow
if true it would be interesting
|
|
Status: Offline |
|
|
megol
|  |
Re: News about Vampire and Apollo Posted on 12-Dec-2017 14:39:33
| | [ #1437 ] |
|
|
 |
Regular Member  |
Joined: 17-Mar-2008 Posts: 355
From: Unknown | | |
|
| @OlafS25
People do use 68k processors with MMU for other things than developing tools. And they don't necessarily use it for Linux - which isn't a really good target for 68k systems anyway for many reasons. Just because you don't use that part of the 68k architecture doesn't mean it isn't part of it.
If the claims were that their "68080" was a semi-compatible processor designed for Amiga systems and not supporting the tools the Amiga platform already have - fine. Now go read what is claimed.
Glad you brought up the FPU. Why are there added hardware for supporting a software FPU emulation when the hardware FPU already was done and just needed to be tested before being enabled?
-- Note: things tend to get removed from the Apollo forum when things change, something crazy is said by the team or someone knowing their stuff pointing out some problem. A good reason not getting involved. Another good reason is that people noticing obvious failures (I'd say lies) in testing and comparisons are called liars, trolls and a lot more. Disgusting. |
|
Status: Offline |
|
|
OlafS25
|  |
Re: News about Vampire and Apollo Posted on 12-Dec-2017 14:50:12
| | [ #1438 ] |
|
|
 |
Elite Member  |
Joined: 12-May-2010 Posts: 6472
From: Unknown | | |
|
| @megol
I owned a A4000 with 68EC030 processor and I am not aware of anything not working on it
which software except debugging tools needs MMU?
You and Kolla have different views of what compatible means compared to Gunnar and the other members of the team. It is ok, you do not need to buy it. Kolla claims to own vampires, I adviced him to sell the cards what is easy at the moment. Problem solved... win-win for everyone. I do not understand the purpose of the moaning. Again gunnar defined compatible to implement the 68k command set, others like you look at it different.
Regarding FPU what are you talking about?
Gunnar wrote that they have a working FPU but it is not integrated and tested, it had no priority but that would change if someone not only makes noise but steps in. Regarding FPU someone stepped in writing the emu layer so FPU had higher priority. The current FPGAs are too small so the FPU does not fit in so the software layer is needed. Newer hardware will have full FPU in hardware. What is so difficult to understand? Last edited by OlafS25 on 12-Dec-2017 at 02:54 PM.
|
|
Status: Offline |
|
|
megol
|  |
Re: News about Vampire and Apollo Posted on 12-Dec-2017 17:15:59
| | [ #1439 ] |
|
|
 |
Regular Member  |
Joined: 17-Mar-2008 Posts: 355
From: Unknown | | |
|
| @OlafS25
Did you read before posting? If so I think you maybe missed something or alternatively misunderstood something. Please re-read.
Previously including a full hardware FPU in existing FPGAs wasn't a problem if I remember correctly. But being a human I may not.
Just so people don't think I'm just a "hater" I think the Apollo core is a great step forward for the Amiga and 68k in general. That doesn't mean I'll stop pointing out things I (and others) think are wrong.
You crap about selling a working accelerator because one doesn't like some things about the project is childish. Do you also think one can't criticize anything if one owns it? If so you must have a very limited life. |
|
Status: Offline |
|
|
Overflow
 |  |
Re: News about Vampire and Apollo Posted on 12-Dec-2017 18:14:08
| | [ #1440 ] |
|
|
 |
Super Member  |
Joined: 12-Jun-2012 Posts: 1628
From: Norway | | |
|
| @megol
I have no problems reading spesific and objective commentary regarding features of Apollo and Vampire, including limitations/lack of features. But quite often posts goes from objective to subjective, people unable to contain themselves in a negatively loaded way. On both sides of the argument.
You have issues with Gunnars approach to the MMU. But Matthew Garrett (if a real account) seems inclined to work with the current version if given details of the instructions. What stops you from doing the same? Maybe its cause of disagreements regarding the roadmap, and hence you wont work with them no matter what they do...? Unless they change their roadmap to mirror the legacy features 100%?
And with regards to FPU, Jari decided to code instead of do fencing on forum. The SoftFPU performance was pretty horrific initially, but as development advances, so does performance. Jari has posted about the assistance he has gotten from the Apollo Team advancing his SoftFPU, and it came about once Jari showed REAL intrest in helping advance the project. Im sure kolla would get more favorable reactions from the team if he offered real assistance/development instead of sour grapes.
If unable to assist due to lack of knowledge or available free time, then its up to the Team itself to allocate their focus how they see fit. |
|
Status: Offline |
|
|