Home   News   Concept   AMIGA-Compatible   Hardware   Forum   Questions+Answers   Pictures   Contact & Team

Welcome to the Natami / Amiga Forum

This forum is for AMIGA fans interested in the new NATAMI platform.
Please read the forum usage manual.



All TopicsNewsQAFeaturesTalkTEAMLogin to post    Create account
Do you have questions about the Natami?
Post it here and we will answer it!

68050/68070 Vs ARM Cortexpage  1 2 
Cesare Di Mauro
Italy

Posts 528
15 Oct 2010 08:03


Gunnar von Boehn wrote:

Cesare Di Mauro wrote:

  Unfortunately, index address extension word(s) need to be read before knowing the exact instruction size.
  That was the major issue for the 68020+ decoder.
 

 
  This is true.
  This gave us headaches for quite a while.
 
  But we solved this with the 68050 design.

Have you made use of I-Cache "tags" to mark istructions begin/end?

Gunnar von Boehn
Germany
(Moderator)
Posts 5775
15 Oct 2010 08:54


Cesare Di Mauro wrote:

Gunnar von Boehn wrote:

 
Cesare Di Mauro wrote:

  Unfortunately, index address extension word(s) need to be read before knowing the exact instruction size.
  That was the major issue for the 68020+ decoder.
 

 
  This is true.
  This gave us headaches for quite a while.
 
  But we solved this with the 68050 design.
 

  Have you made use of I-Cache "tags" to mark istructions begin/end?

Yes.
You need to do something like this to get reach high clockrates with the 020 modes and to reach high clockrates in combination with super scalarity on the 68K.

By reusing this tag feature we could add the proposed new address modes using prefixes  without any drawbacks.


Megol .

Posts 690
15 Oct 2010 11:29


Gunnar von Boehn wrote:

 
Cesare Di Mauro wrote:

  Unfortunately, index address extension word(s) need to be read before knowing the exact instruction size.
  That was the major issue for the 68020+ decoder.
 

 
  This is true.
  This gave us headaches for quite a while.
 
  But we solved this with the 68050 design.
 

  The only real solution is massive parallel decoders for length determination, caching the instruction lengths are more of a hack.
  (IMHO - no negative implications with the word hack btw)
 

Cesare Di Mauro
Italy

Posts 528
15 Oct 2010 13:25


It isn't an hack: it's a well known and used technique by Intel and AMD in their x86 implementations.

Megol .

Posts 690
15 Oct 2010 16:12


Cesare Di Mauro wrote:

  It isn't an hack: it's a well known and used technique by Intel and AMD in their x86 implementations.
 

  It's still a hack. It's a hack as it doesn't solve the problem but merely circumvent it. Branch prediction is a hack too for the same reason. Dynamic memory disambiguation too.
  Intel have never used it since Pentium Pro and AMD will not use it in their planned future cores AFAIK. It's cheaper power-wise to recalculate instruction limits instead of storing it.
(Again: nothing negative meant)

Cesare Di Mauro
Italy

Posts 528
15 Oct 2010 20:08


Megol . wrote:

Cesare Di Mauro wrote:

  It isn't an hack: it's a well known and used technique by Intel and AMD in their x86 implementations.

  It's still a hack. It's a hack as it doesn't solve the problem but merely circumvent it.

It's questionable. If it works, I consider it a solution. :P
Branch prediction is a hack too for the same reason.

Hum. Do you prefer predication (ARM? Or Itanium?)
Dynamic memory disambiguation too.

It's a good idea. :)
Intel have never used it since Pentium Pro

That was logical: the Pentium was able to execute at most two (serial) instructions.

The Pentium Pro raised the number to three, OoO, so it needed a more efficient way to know how many and what kind of instructions will have to execute.
and AMD will not use it in their planned future cores AFAIK. It's cheaper power-wise to recalculate instruction limits instead of storing it.
  (Again: nothing negative meant)

That's a news for me. I have to find some information about it. :P

posts 26page  1 2