Welcome, Guest. Please login or register.

Author Topic: Second NatAmi MX board assembled!  (Read 13551 times)

Description:

0 Members and 2 Guests are viewing this topic.

Offline vidarh

  • Sr. Member
  • ****
  • Join Date: Feb 2010
  • Posts: 409
    • Show all replies
Re: Second NatAmi MX board assembled!
« on: April 13, 2011, 09:15:54 AM »
Quote from: Forcie;631376
The goal is to run AmigaOS and AROS, and they do not need MMU:s.


They might not *need* MMU, but partial memory protection for AROS using MMU is in the works. Personally I see this as the biggest drawback of the Natami. It's still awesome enough that I'll buy one, but it'd be a lot more interesting with a MMU - nothing would prevent  you from making it optional (e.g. possible to turn it on/off at boot time or runtime) so it doesn't affect performance for those who don't want it... But I accept that there doesn't appear to be much support for the idea of a full MMU in your team (based on the public forum discussions, at least).
 

Offline vidarh

  • Sr. Member
  • ****
  • Join Date: Feb 2010
  • Posts: 409
    • Show all replies
Re: Second NatAmi MX board assembled!
« Reply #1 on: April 13, 2011, 10:23:48 AM »
Quote from: Forcie;631385
It is just not that simple. The entire CPU design has to be rethought and reworked if a MMU is to be included, even if it could be turned off. And even if it could be turned off, it would affect the design performance-wise. So it is not a realistic option for the close future.


I'm curious as to why this would be the case for the Natami CPU designs. It'd require some quite odd design decisions, IMHO.

Every "real" 680x0 design since the 68010 has been able to support a fully external MMU just by supporting full recovery after a bus fault and external bus mastering.

With those two features in place, the CPU doesn't need to know whether or not the MMU is there or not. The only way the CPU would "notice" the presence of a MMU would be that it'd occasionally lose bus access or get a bus fault if the MMU had a TLB miss or an access violation respectively - if the MMU isn't present, nothing would interfere with memory accesses.

Many early MMU designs did this. Sun and others even managed to do this with plain 68000's, though doing this on a 68000 required some pretty nasty "magic" and/or running two 68000's in parallel on the same instruction stream (yikes, but it worked), offset so that you could halt and restart the second CPU when the first caused an access violation (because the trapped instructions are not fully restartable).

A MMU design that slowed down the CPU when it's turned off would a be a major design flaw, IMHO, as there's no good reason for that to be the case at all. Most designs with MMU's only ever "lose" cycles due to the presence of the MMU if there's a TLB miss or access violation even when the MMU is on.
 

Offline vidarh

  • Sr. Member
  • ****
  • Join Date: Feb 2010
  • Posts: 409
    • Show all replies
Re: Second NatAmi MX board assembled!
« Reply #2 on: April 13, 2011, 04:53:51 PM »
Quote from: SamuraiCrow;631453
IIRC, the N68050 shares its memory controller with the SuperAGA chipset.  This makes external mastering difficult.  


That certainly does qualify as "odd". Fair enough tradeoff I suppose, though a pity given the loss of functionality.

Quote

Also, the bus faulting requires a few extra stages in the pipeline which will make the CPU suffer more dramatic performance losses if code doesn't follow a linear path (eg. with branching).


Sounds strange. You shouldn't need more than the ability to effectively halt execution, clear the pipeline and store the full user-observable state (all registers, condition codes and the PC value at the start of the instruction as well as information of the access that caused the error) to stack. Then again I'm not privy to the design of the 68050, so maybe there are good reasons.

Of course this would cause a full pipeline stall, but then again when you have to call an exception handler to handle an access violation triggered by an MMU, the cost of a pipeline stall is a rounding error.
 

Offline vidarh

  • Sr. Member
  • ****
  • Join Date: Feb 2010
  • Posts: 409
    • Show all replies
Re: Second NatAmi MX board assembled!
« Reply #3 on: April 13, 2011, 10:05:29 PM »
Quote from: Bamiga2002;631494
It left me the impression that it is not necessarily needed anywhere but debugging and that can be done within WinUAE.


It's not "needed" if you're happy with AmigaOS 3.x the way it is (vs. taking advantage of it as AROS gains at least basic memory protection) and/or is happy with not being able to seriously use it for software development without frequent reboots and/or using the 68060 daughterboard.

For a lot of users that's perfectly fine.

But it sucks in that it makes it a massive pain to use for software development without adding a quite significant expense of a 60860. If I'm going to be using UAE anyway it defeats a lot of the point of getting a Natami in the first place.

It doesn't suck enough that it'll prevent me from buying one, but it does limit my interest somewhat.