Coldfire status

[Doobrey]

@motorollin,
 'Cos it'd mean trying to make a deal with Amiga Inc to get a license and the sources?(IIRC, they don't have the sources to 3.5+3.9 so patching that could be another problem)

[utri007]

Sorry you don't know differenze about kickstart an exec

[Troika]

@Piru

>>Anyway, I'd love to be wrong here, I'd love to see 266MHz m68k, but I believe I won't see that.<<<

I have a soft spot for CF for different reasons, its very cheap for the amount of cash to purchase a CPU.   Prices on some of the Power PC stuff is now coming inline but overall Powerpc is/was more expensive.

[jdiffend]

Piru wrote:
It depends on if you want to fail randomly or not. Personally I wouldn't want to have such code in my system, but that's just me.

Scuse me but there is no randomness to it at all.
And good for you.

[starf81]

OT for Munchkin!

Sorry for my OT... your avatar is great!!!
I'm both an Alfa Romeo and Amiga fun... great great great!!!  :-D  :-D  :-D

Alex

[jdiffend]

utri007 wrote:
Piru is moust likely one of the world, he knows much amiga hardware.

Actually, you need to know the guts of the AmigaOS more than Amiga hardware.  All you do with the hardware is exactly what the old OS does.  It may take more instructions but it's not that big of a deal.  The OS is written to deal with faster CPUs so timing shouldn't be an issue within the OS.

 :roll: I'd at least want someone working on it that knows that Amiga executables are normally stored on disk with separate hunks for code, data and bss sections and that it's easy to have a program scan through an executable file, find a code hunk, search for a numeric pattern of an illegal instruction and then patch it.  There was a program that did this with a 68000 instruction that was used in some early Amiga software that was illegal on the 68010 or higher.  But then that was before the Amiga 500 was even introduced so he may not remember that.  Still, the hunk info is even on a Wiki page.  

So would you like to wrote new amiga exec for coldfire ?

Actually, there is a code translator that can convert most 68K assembly to Coldfire code but last I checked it still hadn't been updated to support the 4e core which requires fewer changes.  Whenever the converter doesn't know what to do it marks the code and you can do it by hand in those spots.  I tested it on some code but not the exec due to differences in the superviser register mode in the colfire chips it supports.  Without support for the 4e core's addition to the supervisor mode the translator is almost useless on supervisor code.  At least as far as the Amiga exec goes... it depends heavily on the register that is missing on all but the 4e coldfires.

However, with the disassembly I have and an updated translator the exec itself wouldn't be that bad.  The most work to the exec would be to support the stack frame differences for interrupts and integration of the instruction traps.  There's still probably more than a month of work there.  Without the conversion tool it would take a very long time.  The exec has a lot of code.

At that point the Coldfire could run through the self tests, setup the timer device (which would also need to be native Coldfire code), set up memory, autoconfig devices, setup graphics/intuition and move to the bootup sequence.
Then you have to see what fails and fix that.

We need positive additude in this dark time.

I'd settle for a lot less FUD.

[Piru]

@jdiffend

Scuse me but there is no randomness to it at all.

Yes it does. Such executable scanning method can never catch all instructions, and it will patch data, making the program malfunction. This causes random failures.

Actually, you need to know the guts of the AmigaOS more than Amiga hardware.

Funny, I know AmigaOS internals much better than any HW stuff. :-)

I'd at least want someone working on it that knows that Amiga executables are normally stored on disk with separate hunks for code, data and bss sections and that it's easy to have a program scan through an executable file, find a code hunk, search for a numeric pattern of an illegal instruction and then patch it.

Well, clearly you don't know that code hunks also contain data, and data hunks can contain code. Thus it is impossible to be sure if some specific bit pattern is code or data.

If you still disagree with me, provide me a routine that will scan executable file and dump which parts of it are code and which are data.

Good luck.

[platon42]

@jdiffend:

Sorry to interfere, but I'd suggest you check Harry 'Piru' Sintonens background and references before you continue to doubt the things he says. I suppose only a hand full of people (if any) know more about the amiga internals than Piru.

And no, there is *no* way to find out if a word in a data or code section is code or data -- other than doing a full CPU emulation and stepping through the code that's reached (and still this will not yield the sections that contain dead or exceptional code). Though there are code and data hunks in an executable, nothing ever has prevented a coder to mix the contents at his will.

And also with my own technical background, I don't see how a ColdFire board could ever *work* (regardless of the performance) without full CPU emulation, especially regarding those non-compatible instructions with different behaviour or side-effects, that cannot be trapped and then emulated on the fly.

My conclusion is: The Dragon is never going to work in an amiga system, or, if it does, it would be using full CPU emulation (possibly with JIT?*), and hence, unbearably slow -- much slower than an MC68060/040.

* I don't think Elbox has technically enough skilled people to write something like a JIT compiler.

[Karlos]

Just to add my random thoughts....

Coldfire _in theory_ might possibly run a pretty fast 68K JIT. If you look up HP's Dynamo technology, you'll see what I mean.

Of course JIT has overheads too, transcription times being one of them, and a pretty big one for slower CPUs at that. This, however, is where the coldfire could do well in that transcription for a lot of instructions (basically all the implemented ones) wouldn't really involve much more than copying them.

This all hinges, of course, on someone having the time and skill to develop it. Oh, and it being feasable to do in the first place, which I freely admit might prove a little bit tricky :-)

[Karlos]

Piru wrote:

Elbox also has some nice habit of using theoretical values out of context in their marketing material. For example the "266MB/s transfer speed" of the Mediator (PCI vs PCI speed is irrelevant with mediator, as the bus between the system and the pci-subsystem is ridiculously slow, and surprisingly this more important speed is not mentioned anywhere...).

Whaddaya mean? 8MB/s CPU driven transfer from system to PCI ought to be enough for anybody!

:lol: ;-)

[FrenchShark]

Hello,

I think you are talking about me :-)
I do have the exec.library ported to the coldfire 5282 (it was the first coldfire to have the USP/SSP implementation).
This coldfire exec.library is not compatible witht the 68k exec.library because of some differences in ExecBase!
For example, IDNestCnt and TDNestCnt have to be LONG since addq.b does not exist on CF and you cannot replace the addq.b by multiple instructions : the update of IDNestCnt and TDNestCnt must be done with one atomic instruction.
I have also a piece of timer.device translated into CF, it is necessary for the time slice part of the multi-tasking.
The project was put on hold, between the work and the family, it is hard to find some time.

Oh, BTW I had a though about how to provide a full CPU emulation on the Coldfire : we can use the trace mode and check if the instruction is compatible : when it is compatible you exit the exception and let the CF do the work when it is not you execute the emulated code. You can also use the debugging registers to separate the memory into two areas : one containing 68k code, one containing CF code (CF kickstart, libraries compiled for CF, etc...)

Regards,

Frederic

[Piru]

Oh, BTW I had a though about how to provide a full CPU emulation on the Coldfire : we can use the trace mode and check if the instruction is compatible : when it is compatible you exit the exception and let the CF do the work when it is not you execute the emulated code.

I tried this approach once on 68060@64. The result was slower than 68000@7 (constant exceptions really kill the performance it seems, must be the stack memory accesses).

Maybe coldfire 5282 exceptions aren't as slow as 68060, though?

[MskoDestny]

platon42 wrote:
And no, there is *no* way to find out if a word in a data or code section is code or data -- other than doing a full CPU emulation and stepping through the code that's reached

That's not completely true. Unless part of the code is compressed, encrypted or generated on the fly you can theoretically start scanning at the entry point and just follow all the possible branches. Jump tables are a little tricky in part because it can be difficult to figure out the bounds of the table; however, with the 68K family it's a little easier as disassembling random data tends to produce illegal instructions within a short period of time. It would be difficult to make it fool-proof, but you could probably get pretty close, especially on code compiled from something higher level than assembly.

[Piru]

@MskoDestny

Theoritically that indeed is possible but it still is quite futile attempt, as lot of stuff could still go unnoticed. And you would end up with some sort of emulation anyway, at least if you want to cover dynamic branches (jsr, jmp).

Also this method would not cover things like interrupts, hooks and callbacks being called indirectly from OS functions.

Some of the antivirus systems have some sort of emulation to handle decompression of polymorhic viruses, that kind of technology would be the most usable I guess. But then you end up writing full emulation with state preservation just to determine if something is code or data... ;-)

[MskoDestny]

Piru wrote:

Oh, BTW I had a though about how to provide a full CPU emulation on the Coldfire : we can use the trace mode and check if the instruction is compatible : when it is compatible you exit the exception and let the CF do the work when it is not you execute the emulated code.

I tried this approach once on 68060@64. The result was slower than 68000@7 (constant exceptions really kill the performance it seems, must be the stack memory accesses).

Maybe coldfire 5282 exceptions aren't as slow as 68060, though?

It's the stack memory accesses, plus flushing the pipeline, plush thrashing the instruction cache. Given that faster processors generally have longer pipelines I doubt the situation would be any better on Coldfire; it would most likely be worse.

[Piru]

Yeah. 68060 spends 19 cycles per instruction on trace exception (1 read, 3 write cycles), and that is not counting the actual exception code itself (except fetching the first instruction).

Considering normally 68060 spends only couple of cycles per inst in average, this is quite slow indeed.