Coldfire status

[Piru]

Dragon FAQ written by who?

[Piru]

@amije

Nah, but if you were to market something, would you highlight the obvious defects in your product, or try to downplay them?

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...).

[Piru]

@boing

Also the speed of the ColdFire running 6K code is easily answered by looking that the instructions, addressing modes and registers offered by by both the 68000-68060 and and Specific ColdFire chip used by Elbox (or other company).

In fact I'm sure Moto/FreeScale has a comparison chart buried somewhere on their site.

Actually it's more complex than that. It depends on the frequence of the emulated instructions in the specific code being executed, and the method of emulation used. IMO to be usable the Dragon m68k emulation should be complete (and not fail with multiplication overflow and such stuff, and it should emulate supervisor mode). To get this you'd need full emulation of both user and supervisor mode. This is not fast on 266MHz chip.

jdiffend already covered some other stuff regarding this, but you can also visit the other threads (use the search function).

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

Still, Elbox can easily prove me wrong by releasing the thing and having it perform as promised.

[Piru]

Software could be written to scan through a program looking for the mul/div instructions where they wouldn't function the same. They could be replaced with an illegal instruction that could be trapped just like the others.

That doesn't work well. The problem is that there is no way to determine if some value is code or data. Checksums would also be a problem (just try running xvs.library or elbox drivers when the code has been modified, for example).

[Piru]

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.

[Piru]

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

Seriously? No.

I've brought up my reasons often enough. I think using coldfire isn't that good idea.

Anyway, maybe I'm wrong and it'll work out. We'll see.

[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.

[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?

[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... ;-)

[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.

[Piru]

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

...and it seems I wasn't wrong. Elbox themselves quote performance between 040 and 060. From the videos it looks more on the 040 side.