Welcome, Guest. Please login or register.

Author Topic: Coldfire - Binary Compatible  (Read 7679 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Hammer

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 1996
  • Country: 00
    • Show only replies by Hammer
Re: Coldfire - Binary Compatible
« Reply #119 from previous page: February 04, 2008, 09:26:15 AM »
Quote

AeroMan wrote:
Quote

Hammer wrote:
CELLs based products such as Toshiba's SpurEngine (10W to 20W part) doesn't have PPE


This still doesn't mean that nobody will ever have interest in producing a chip with the PPE

Quote

I'll bet it doesn't have a PPC in its critical computing systems.


Delphi, Marelli and Bosch uses PPCs in engine control modules. This is quite critical to me.
The V850 is a great chip, and it was well chosen to power Toyota's cars. Some people are driving Renesas, some ST, and I even had a experience with TI some years ago (not a really good one. We went back to Motorola, but the chip was nice).
Nobody, as far as I know, is using x86, for a couple of reasons. Unless Toshiba decides to install wheels in their HD-DVDs

One may say Toshiba has installed wheels in their HD-DVDs.

Refer to http://news.thomasnet.com/companystory/525623

Toshiba Selects ARM Cortex-M3 Processor for Automotive Applications.

As for X86 for control CPU... Refer to
Underwater Vehicle Control software

"The Underwater Vehicle Control software is incorporated. into the MissionP software, which runs on a low-power X86. CPU"

Amiga 1200 PiStorm32-Emu68-RPI 4B 4GB.
Ryzen 9 7900X, DDR5-6000 64 GB, RTX 4080 16 GB PC.
 

Offline arnljot

Re: Coldfire - Binary Compatible
« Reply #120 on: February 08, 2008, 12:53:34 AM »
Browsing for something copletely different I found this site:
http://www.cdtv.org.uk/coldfire/

This effort now seems dead since 2004. Did this have anything to do with Elbox?
A posting a day keeps the sanity away...
http://www.arnljot.com
 

Offline bloodline

  • Master Sock Abuser
  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 12113
    • Show only replies by bloodline
    • http://www.troubled-mind.com
Re: Coldfire - Binary Compatible
« Reply #121 on: February 08, 2008, 01:08:03 AM »
Quote

arnljot wrote:
Browsing for something copletely different I found this site:
http://www.cdtv.org.uk/coldfire/

This effort now seems dead since 2004. Did this have anything to do with Elbox?


No, that is Oli_HD's home project... Send him a PM :-)

Offline arnljot

Re: Coldfire - Binary Compatible
« Reply #122 on: February 08, 2008, 01:26:28 AM »
Quote

bloodline wrote:
No, that is Oli_HD's home project... Send him a PM :-)


Nah, too shy :-)

Is he still working on this?
A posting a day keeps the sanity away...
http://www.arnljot.com
 

Offline bloodline

  • Master Sock Abuser
  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 12113
    • Show only replies by bloodline
    • http://www.troubled-mind.com
Re: Coldfire - Binary Compatible
« Reply #123 on: February 08, 2008, 01:45:54 AM »
Quote

arnljot wrote:
Quote

bloodline wrote:
No, that is Oli_HD's home project... Send him a PM :-)


Nah, too shy :-)

Is he still working on this?


He's a nice enough chap... He'll tell you all about it if you ask him... I don't think he works on it any more, though I could be wrong.

Offline Oli_hd

  • Hero Member
  • *****
  • Join Date: Apr 2002
  • Posts: 912
    • Show only replies by Oli_hd
Re: Coldfire - Binary Compatible
« Reply #124 on: February 08, 2008, 02:13:41 AM »
Hello :)
 

Offline arnljot

Re: Coldfire - Binary Compatible
« Reply #125 on: February 08, 2008, 03:09:11 AM »
Quote

Oli_hd wrote:
Hello :)


LOL, hello. Are you working on your coldfire accellerator?
A posting a day keeps the sanity away...
http://www.arnljot.com
 

Offline jarrody2k

  • Full Member
  • ***
  • Join Date: Feb 2002
  • Posts: 126
    • Show only replies by jarrody2k
Re: Coldfire - Binary Compatible
« Reply #126 on: February 08, 2008, 06:16:54 AM »
Quote

Piru wrote:
@lou_dias
Quote
Why couldn't a 68K be virtualized and then fed the binary, then the virtual68k could make the determination and in the background, the app is repackaging the binary in a Coldfire-compatible way. The resultant binary could then be run natively.

Because it is impossible to tell whether certain part of the binary is code or data.

If I understood correctly you're suggesting here that the program would be run and that the executed parts would be translated? This doesn't work: There is no way to get any given program to run all code paths.

The only way is to do the translation on the fly: JIT.


Theoretically I can't see why not... executables have an entry point, and libraries will have some table of functions.  If you start at the entry point and take both directions on each possible conditional branch... why not?  I guess self modifying code may cause a problem, perhaps also jump thunks.... or any code jumps that jump to locations based on run-time variables.. and a lot of that stuff is more prominent in C++ templates and game code.  But certainly a lot of C executables could be converted with relative ease.

Not a robust solution or anything that would be used for general purpose emulation, but it isn't outright impossible.

Until Lord Piru corrects me ;)

Jarrod
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: Coldfire - Binary Compatible
« Reply #127 on: February 08, 2008, 09:39:50 AM »
@jarrody2k

Basically you'd need to emulate the whole program then. Just splitting at branches is not enough. You correctly note the dynamic jumps: this is a huge problem. There also are many points where the code are called from within the OS: For example interrupts, hooks and other callbacks.

So not only you'd need to emulate the m68k processor, you'd also need to trap every possible OS call. Also, some 3rd party library/device/whatever might be called that jumps into the the code, again generating a problem.

To correctly interpret everything would require running all possible codepaths in simulated environment. How does your simulation know when it's done? Running all possible codepaths in a given program take time x (x can be infinite). Running the same in emulation is not going to be faster than that.
 

Offline Oli_hd

  • Hero Member
  • *****
  • Join Date: Apr 2002
  • Posts: 912
    • Show only replies by Oli_hd
Re: Coldfire - Binary Compatible
« Reply #128 on: February 08, 2008, 04:39:08 PM »
Quote
hello. Are you working on your coldfire accellerator?

After the last prototype failed to work Ive been playing around with other things, I will be making a new prototype but doubt you will see a finished product from me, sorry.

I will keep working on it though as I would much rather see a Coldfire Amiga than a PPC board. (even though Im using a Cyberstorm PPC at home)
 

Offline Iggy_Drougge

  • Sr. Member
  • ****
  • Join Date: Jul 2003
  • Posts: 333
    • Show only replies by Iggy_Drougge
    • http://www.kristallpojken.org
Re: Coldfire - Binary Compatible
« Reply #129 on: February 09, 2008, 01:05:24 AM »
A4000/25MHz/64MB/20GB/RetinaBLTZ3/FastlaneZ3/CatweaselMKIII/Ariadne/A2301
A3000/40MHz/32MB/6GB/Merlin/Buddha/X-Surf/FrameMachineII+Prism24
Draco60/50MHz/128MB/15GB/Altais/DracoMotion/DV/IOblix+net
 

Offline Iggy_Drougge

  • Sr. Member
  • ****
  • Join Date: Jul 2003
  • Posts: 333
    • Show only replies by Iggy_Drougge
    • http://www.kristallpojken.org
Re: Coldfire - Binary Compatible
« Reply #130 on: February 09, 2008, 01:05:47 AM »
(double post)
A4000/25MHz/64MB/20GB/RetinaBLTZ3/FastlaneZ3/CatweaselMKIII/Ariadne/A2301
A3000/40MHz/32MB/6GB/Merlin/Buddha/X-Surf/FrameMachineII+Prism24
Draco60/50MHz/128MB/15GB/Altais/DracoMotion/DV/IOblix+net
 

Offline jarrody2k

  • Full Member
  • ***
  • Join Date: Feb 2002
  • Posts: 126
    • Show only replies by jarrody2k
Re: Coldfire - Binary Compatible
« Reply #131 on: February 16, 2008, 07:45:04 AM »
Quote

Piru wrote:
@jarrody2k

Basically you'd need to emulate the whole program then. Just splitting at branches is not enough. You correctly note the dynamic jumps: this is a huge problem. There also are many points where the code are called from within the OS: For example interrupts, hooks and other callbacks.


If the OS does call to the program, the program needs to let the OS know where to jump to.  These function calls could be located and determined within translated code and the numbers changed to the new locations in the program.  I presume it would be quite possible (maybe not trivial) to detect kernel function calls or native library calls of the particular OS functions that register callbacks/interrupts etc.

For the locations it does register, these should also be translated.  So if the program registers some event response code for a button click, the code that is executed after that button click should be translated also.

Quote

So not only you'd need to emulate the m68k processor, you'd also need to trap every possible OS call. Also, some 3rd party library/device/whatever might be called that jumps into the the code, again generating a problem.


Surely libraries have some sort of function table where the entry points could be adjusted?

But certainly if code does tell another device/library to call back at a fixed point in code in a non-os friendly or unforseen way, this would be difficult to fix.

Quote

To correctly interpret everything would require running all possible codepaths in simulated environment. How does your simulation know when it's done? Running all possible codepaths in a given program take time x (x can be infinite). Running the same in emulation is not going to be faster than that.


Of course, any branches that branch back into already-translated code segments would terminate.  I hardly think you could make an accurate progress bar apart from the amount of code translated versus the total binary size (of which will be partly data sections)... but all paths will come to an end because they will eventuall skip to another part in code that is already translated or will return control to the OS.

I am not saying any of this is trivial, far from the case.  I am saying it is possible, and dare I say, achievable by an experienced team of software engineers.

Cheers,

Jarrod
 

Offline alexh

  • Hero Member
  • *****
  • Join Date: Apr 2005
  • Posts: 3644
    • Show only replies by alexh
    • http://thalion.atari.org
Re: Coldfire - Binary Compatible
« Reply #132 on: February 16, 2008, 08:02:22 AM »
Quote

jarrody2k wrote:
I am saying it is possible, and dare I say, achievable by an experienced team of software engineers.

As an experience software (and hardware) engineer. I'm saying it isn't.
 

Offline bloodline

  • Master Sock Abuser
  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 12113
    • Show only replies by bloodline
    • http://www.troubled-mind.com
Re: Coldfire - Binary Compatible
« Reply #133 on: February 16, 2008, 11:14:42 AM »
@Jarrod

I too, used to think that a static translation would be possible... Instead of arguing, I compiled some C source code (I forget the program) then assembled it to object code, then disassmbled the object code and manually tried to convert the resultant 68k in to PPC assembler... I remember hitting a wall and asking questions on this very forum only to discover that there were descisions that I needed to make that only the original coder knew the reasons for and I would only be able to determine at run time. Basically you hit the same problem the VLWI guys hit when they tried to take the RISC concept to the extreme.