Freescale Coldfire V4s

[Fats]

There is no way to tell which part of the binary is code and which data. If you translate data in similar manner you'll just corrupt it.

What you do know is that the program entry is code. You can start from there and put traps in sections where you are not sure (e.g jmp tables etc.). You could combine it with a cache that remembers translated code.
In a later stage you can make tools that makes binary patches from this cache so this information can be distributed or updated so that the loader doesn't need to find out each time it loads a program.
Non-trivial job, I agree, but what would we hobby programmers do otherwise ?

greets,
Staf.

[bloodline]

What you do know is that the program entry is code. You can start from there and put traps in sections where you are not sure (e.g jmp tables etc.). You could combine it with a cache that remembers translated code.
In a later stage you can make tools that makes binary patches from this cache so this information can be distributed or updated so that the loader doesn't need to find out each time it loads a program.
Non-trivial job, I agree, but what would we hobby programmers do otherwise ?

greets,
Staf.

I think the key here is that any work you would need to do to get 68k executing on the cold fire, would be true of faster, cheaper processors.

I still think Iggy should have some fun with this project (this is the whole point of AROS after all), but be under no illusions of good or even passable 68k compatiblity

[Piru]

What you do know is that the program entry is code. You can start from there and put traps in sections where you are not sure (e.g jmp tables etc.). You could combine it with a cache that remembers translated code.
In a later stage you can make tools that makes binary patches from this cache so this information can be distributed or updated so that the loader doesn't need to find out each time it loads a program.

No, it still won't work. This doesn't account for code that dynamically jumps into various parts of code or performs run-time modifications to the code. Static analysis cannot account for these.

The only way to do this reliably is to perform the translation run-time, that is JIT.

[Zac67]

What you do know is that the program entry is code. You can start from there and put traps in sections where you are not sure (e.g jmp tables etc.).

This is what I was referring to - you should be aware that this is a manual task as exhaustively doing this in software is not possible (except for trivial programs). Someone has to check/patch the 68k code and (hopefully) share his findings with others through a database on the 'net which the binary loader uses in turn to patch code while it's being loaded. Not likely to happen.

[Iggy]

No, it still won't work. This doesn't account for code that dynamically jumps into various parts of code or performs run-time modifications to the code. Static analysis cannot account for these.

The only way to do this reliably is to perform the translation run-time, that is JIT.

Piru is absolutely right that self modifying code will never work via a translation process, thus requiring JIT.
And as bloodline has pointed out this is better suited to faster processor.
And again, bloodline has pointed out that this is just a project for the fun of it.
Don't expect me to leave behind NG OS' anytime soon.

[Fats]

No, it still won't work. This doesn't account for code that dynamically jumps into various parts of code or performs run-time modifications to the code. Static analysis cannot account for these.

For run-time modification I agree, dynamically jmp should be able to be trapped by adding trap code like a debugger does.

greets,
Staf.

[Iggy]

For run-time modification I agree, dynamically jmp should be able to be trapped by adding trap code like a debugger does.

greets,
Staf.

I agree that that could be trapped, leaving only self modifying code as a problem.
Besides, its inevitable that some software simply isn't going to run on a system like this (unless it also supports 68k emulation or a soft core).