Coldfire AGAIN

[mongo]

biggun wrote:

The 68k "flags" instruction fetched on the debug pins. (Harvard Architecture).

ColdFire doesn't.

[HenryCase]

bloodline wrote:
Hmmm... this is going to turn into CPU 101...

I'm willing to learn. You never know, through my ignorance a good idea may emerge.

bloodline wrote:
The CPU makes requests to the Memory, sometimes those requests will be for an instruction, sometimes those requests will be for Data (as requested by an instruction).

Does the outgoing instruction know what it is requesting, or is it simply calling on a set memory space? Also, does memory get divided up into program space and data space or is it all jumbled up?

[bloodline]

HenryCase wrote:

bloodline wrote:
Hmmm... this is going to turn into CPU 101...

I'm willing to learn. You never know, through my ignorance a good idea may emerge.

I used to think that... sadly, while ignorance used to allow abstract thinking, now is just causes you to fall into the same traps that people in the past have. It is always best to stand on the shoulders of giants :-)

bloodline wrote:
The CPU makes requests to the Memory, sometimes those requests will be for an instruction, sometimes those requests will be for Data (as requested by an instruction).

Does the outgoing instruction know what it is requesting, or is it simply calling on a set memory space? Also, does memory get divided up into program space and data space or is it all jumbled up?

There is no outgoing instruction. At boot the CPU requests data from a predetermined (by the CPU manufacturer) location, this data will be the first instruction to be executed. Often this first instruction will be a jump instruction, that tells the CPU where to fetch the next instruction from. From there it's up to the system designer what happens... then next instruction could tell the CPU to move Data around the internal registers... or to add a register to a memory location or to copy the data from a location to a register... only the CPU knows :-)

Memory on the Amiga is jumbled up, Code and Data are all over the place... on a x86 it has an MMU that marks memory pages as Code or Data... but then  you would still have the problem of variable length instructions.

[HenryCase]

bloodline wrote:


There is no outgoing instruction.

I worded that badly, I should have used 'outgoing signal' instead. What I'm trying to get at is does the CPU give clues about what it is trying to fetch?

If not outgoing signals then are there CPU pins you can monitor to get information on what the CPU wants to do with the information it gets next?

bloodline wrote:
Memory on the Amiga is jumbled up, Code and Data are all over the place... on a x86 it has an MMU that marks memory pages as Code or Data... but then  you would still have the problem of variable length instructions.

Is the variable length instructions issue not something we can work around? Let's say the 'parasite' is looking for the instruction 0x000189. Whenever this code comes up the 'parasite' looks at the code following it. If it follows the format it is expecting then it tries to use it, if not then it lets the CPU try to handle it.

[bloodline]

HenryCase wrote:

bloodline wrote:


There is no outgoing instruction.

I worded that badly, I should have used 'outgoing signal' instead. What I'm trying to get at is does the CPU give clues about what it is trying to fetch?

If not outgoing signals then are there CPU pins you can monitor to get information on what the CPU wants to do with the information it gets next?

The CPU is not required to let anyone else on the bus know what it is trying to fetch. systems with an MMU (and as Biggun states Harvard Architecture) do provide signals to let other bus users know what's going on, this is useful for multiCPU systems where caches need to be kept coherent. The x86 provides this sort of data...

bloodline wrote:
Memory on the Amiga is jumbled up, Code and Data are all over the place... on a x86 it has an MMU that marks memory pages as Code or Data... but then  you would still have the problem of variable length instructions.

Is the variable length instructions issue not something we can work around? Let's say the 'parasite' is looking for the instruction 0x000189. Whenever this code comes up the 'parasite' looks at the code following it. If it follows the format it is expecting then it tries to use it, if not then it lets the CPU try to handle it.

The problem here is that you would need to simulate the entire frontend of the CPU to follow what's going on... and even then, exceptions and interrupts will throw the whole thing out... I hope now you can see how difficult this idea would be!

Don't forget that an instruction is just a number, that number means something to the CPU, but only the CPU knows if that number is telling the CPU what to do next, or if the CPU needs that number for a calculation.

[HenryCase]

@bloodline

Well I'm convinced enough that the 'parasite' idea isn't worth pursuing now, little more difficult than I had hoped. Thanks for your help bloodline.

@all

Coldfire still shows promise IMO. Maybe we could do a bit of research into 68k-Coldfire compatibility. This should be a good place to start looking:
http://tinyurl.com/3exnxn

Oli hd please contribute to this discussion, your input will be very valuable here.

[bloodline]

HenryCase wrote:
@bloodline

Well I'm convinced enough that the 'parasite' idea isn't worth pursuing now, little more difficult than I had hoped. Thanks for your help bloodline.

No worries, CPU design is a fun topic... I should say, was a fun topic... it's all very complex now... the Amiga was the last of the understandable architectures... now you need teams of people.

Coldfire still shows promise IMO. Maybe we could do a bit of research into 68k-Coldfire compatibility. This should be a good place to start looking:
http://tinyurl.com/3exnxn

Well, the V4 and V5 cores, with their separate supervisor stack do seem to have what it takes to emulate the 68000 (not sure about the data width issues though)... but the instruction traps which will be required are very expensive in terms of CPU cycles... I really do think we are looking at a massive penalty with the coldfire... until I see one in action I can't be 100% sure, but from what I've read I'm not hopeful.

Oli-HD please contribute to this discussion, your input will be very valuable here.

Indeed...

[minator]

You know full well that when you licence a core you don't buy the right to modify it.

That will depend on the exact terms of the license.  These aren't exactly shrink wrap licenses, probably specific to each licensee.

e.g. DEC, the designers of StrongARM had an ARM architectural license, that allowed them to design their own processor from scratch.

[bloodline]

minator wrote:

You know full well that when you licence a core you don't buy the right to modify it.

That will depend on the exact terms of the license.  These aren't exactly shrink wrap licenses, probably specific to each licensee.

e.g. DEC, the designers of StrongARM had an ARM architectural license, that allowed them to design their own processor from scratch.

But for the tiny sums of money (and low production runs) we are talking about, there is no way Freescale would allow any modification to the core.

[HenryCase]

bloodline wrote:
But for the tiny sums of money (and low production runs) we are talking about, there is no way Freescale would allow any modification to the core.

Why would money/low production runs come into it? If the redesign work was done by a 3rd party, and the cost of manufacture was the same, where would Freescale be losing out?

[bloodline]

HenryCase wrote:

bloodline wrote:
But for the tiny sums of money (and low production runs) we are talking about, there is no way Freescale would allow any modification to the core.

Why would money/low production runs come into it? If the redesign work was done by a 3rd party, and the cost of manufacture was the same, where would Freescale be losing out?

That has nothing to do with it, it's about access to the technology. The less you pay the less you are allowed to do with the IP.

-Edit- missing word :-) oops too late :lol:

[HenryCase]

bloodline wrote:

HenryCase wrote:

bloodline wrote:
But for the tiny sums of money (and low production runs) we are talking about, there is no way Freescale would allow any modification to the core.

Why would money/low production runs come into it? If the redesign work was done by a 3rd party, and the cost of manufacture was the same, where would Freescale be losing out?

That has nothing to do with it, it's about access to the technology. The less you pay the you are allowed to do with the IP.

OIC. Fair enough.

[A6000]

bloodline wrote:
Well, the V4 and V5 cores, with their separate supervisor stack do seem to have what it takes to emulate the 68000 (not sure about the data width issues though)... but the instruction traps which will be required are very expensive in terms of CPU cycles... I really do think we are looking at a massive penalty with the coldfire.

As I understand it, the coldfire is cheap, that is really the only thing it has going for it.
The amiga is a multitasking computer, so why not use 2 coldfires, running separate tasks, while one chip is trapping and emulating code, the other coldfire continues running it's task, hiding the speed penalty that emulation brings.
A few extentions to kickstart (in ram) will enable the OS to use 2 processors simultaneously.

[bloodline]

A6000 wrote:

bloodline wrote:
Well, the V4 and V5 cores, with their separate supervisor stack do seem to have what it takes to emulate the 68000 (not sure about the data width issues though)... but the instruction traps which will be required are very expensive in terms of CPU cycles... I really do think we are looking at a massive penalty with the coldfire.

As I understand it, the coldfire is cheap, that is really the only thing it has going for it.

hmmm, it's not that cheap...

The amiga is a multitasking computer, so why not use 2 coldfires, running separate tasks, while one chip is trapping and emulating code, the other coldfire continues running it's task, hiding the speed penalty that emulation brings.
A few extentions to kickstart (in ram) will enable the OS to use 2 processors simultaneously.

Not  chance of Exec supporting 2 CPUs (this would require a complete rewrite, and Memory protection would help). Michal Schulz  and NicJA did some work on getting AROS's Exec SMP ready, but... that was for x86 CPUs which are built for SMP (with extremely powerful MMUs and extensive cache coherency hardware).

Other than that, most Amiga programs spend their time sleeping, so it wouldn't really offer much improvement...

[FrenchShark]

AmigaHeretic wrote:

Sounds very cool.  Are you saying you are emulating all 68k though or you are still just talking about emulating the missing op codes?

I am emulating all 68k opcodes for maximum compatibility.

The core routine is pretty simple :

exec_68k_inst:
  move.w  (A5)+,D6                     ; Read a 68k instruction word
  move.l  D6,D5
  lsr.l   #6,D6                        ; D6 : bits 15-6 (jump table index)
  andi.l  #$3F,D5                      ; D5 : bits 5-0 (effective address)
  movea.w dispatch_tab(PC,D6.l*4),A0   ; A0 : emulation routine address
  movea.w dispatch_tab+2(PC,D6.l*4),A2 ; A2 : effective address table
  move.l  (A2),D0                      ; D0 : offset in the emulation routine
  lea     0(A0,D0.l),A1                ; A1 : patching address
  move.l  4(A2,D5.l*4),(A1)            ; Patch the emulation routine
  jmp     (A0)                         ; Call the emulation routine

Then, the dispatch table:
(first word : routine address, second word : EA table address)

dispatch_tab:
  ;$0000 - $0FFF
  dc.w    inst_ORI_B,ea_ORI_B
  dc.w    inst_ORI_W,ea_ORI_W
  dc.w    inst_ORI_L,ea_ORI_L
  dc.w    inst_illegal,0
  dc.w    inst_BTST_D0,ea_BTST_reg
  dc.w    inst_BCHG_D0,ea_BCHG_reg
  dc.w    inst_BCLR_D0,ea_BCLR_reg
  dc.w    inst_BSET_D0,ea_BSET_reg
  dc.w    inst_ANDI_B,ea_ANDI_B
  dc.w    inst_ANDI_W,ea_ANDI_W
  dc.w    inst_ANDI_L,ea_ANDI_L
  dc.w    inst_illegal,0
  ...

One of the EA table :

;Effective address table for:
; ORI.B  #xx,
; ANDI.B #xx,
; EORI.B #xx,
; ADDI.B #xx,
; SUBI.B #xx,
; CMPI.B #xx,
ea_ORI_B:
ea_ANDI_B:
ea_EORI_B:
ea_ADDI_B:
ea_SUBI_B:
ea_CMPI_B:
  dc.l    2
  lea     reg_D0+3(A6),A0
  lea     reg_D1+3(A6),A0
  lea     reg_D2+3(A6),A0
  lea     reg_D3+3(A6),A0
  lea     reg_D4+3(A6),A0
  lea     reg_D5+3(A6),A0
  lea     reg_D6+3(A6),A0
  lea     reg_D7+3(A6),A0
  dc.w    $4EF8,inst_illegal
  dc.w    $4EF8,inst_illegal
  dc.w    $4EF8,inst_illegal
  dc.w    $4EF8,inst_illegal
  dc.w    $4EF8,inst_illegal
  dc.w    $4EF8,inst_illegal
  dc.w    $4EF8,inst_illegal
  dc.w    $4EF8,inst_illegal
  move.l  reg_A0(A6),A0
  move.l  reg_A1(A6),A0
  move.l  reg_A2(A6),A0
  move.l  reg_A3(A6),A0
  move.l  reg_A4(A6),A0
  move.l  reg_A5(A6),A0
  move.l  reg_A6(A6),A0
  move.l  reg_A7(A6),A0
  dc.w    $4EB8,calc_ea_18_B
  dc.w    $4EB8,calc_ea_19_B
  dc.w    $4EB8,calc_ea_1A_B
  dc.w    $4EB8,calc_ea_1B_B
  dc.w    $4EB8,calc_ea_1C_B
  dc.w    $4EB8,calc_ea_1D_B
  dc.w    $4EB8,calc_ea_1E_B
  dc.w    $4EB8,calc_ea_1F_B
  dc.w    $4EB8,calc_ea_20_B
  dc.w    $4EB8,calc_ea_21_B
  dc.w    $4EB8,calc_ea_22_B
  dc.w    $4EB8,calc_ea_23_B
  dc.w    $4EB8,calc_ea_24_B
  dc.w    $4EB8,calc_ea_25_B
  dc.w    $4EB8,calc_ea_26_B
  dc.w    $4EB8,calc_ea_27_B
  dc.w    $4EB8,calc_ea_28
  dc.w    $4EB8,calc_ea_29
  dc.w    $4EB8,calc_ea_2A
  dc.w    $4EB8,calc_ea_2B
  dc.w    $4EB8,calc_ea_2C
  dc.w    $4EB8,calc_ea_2D
  dc.w    $4EB8,calc_ea_2E
  dc.w    $4EB8,calc_ea_2F
  dc.w    $4EB8,calc_ea_30
  dc.w    $4EB8,calc_ea_31
  dc.w    $4EB8,calc_ea_32
  dc.w    $4EB8,calc_ea_33
  dc.w    $4EB8,calc_ea_34
  dc.w    $4EB8,calc_ea_35
  dc.w    $4EB8,calc_ea_36
  dc.w    $4EB8,calc_ea_37
  movea.w (A5),A0
  addq.l  #2,A5
  movea.l (A5),A0
  addq.l  #4,A5
  dc.w    $4EF8,inst_illegal
  dc.w    $4EF8,inst_illegal
  dc.w    $60F8,$4E71
  dc.w    $4EF8,inst_illegal
  dc.w    $4EF8,inst_illegal
  dc.w    $4EF8,inst_illegal

The emulation routines :

;$0000 - $003F : ORI.B #xx,
inst_ORI_CCR:
  or.l    D1,D7
  rts
inst_ORI_B:
  move.w  (A5)+,D1
  dc.l    0
  move.b  (A0),D2
  or.l    D1,D2
  move    D7,CCR
  move.b  D2,(A0)
  move    CCR,D7
  rts

  ...

Quite straightforward :-D

Regards,

Frederic

[JetRacer]

If I recall correct, the 060 is 32-bit pure and hardware emulates <32-bit by simply stripping the communication since it would take more resources to do it "the right way" (and it wouldn't shave any cycles anyway). As others pointed out: modifying CF to do this is not a viable option. So (finally) my question is: will doing this with JIT have a notable impact on performance?

By "notable" I don't mean a reduction of a vanishing factor 4 in the scope of a x1400 or x140 gain.