Coldfire - Binary Compatible

[bloodline]

freqmax wrote:
Do we really need a softcore-68060, why not try to do 68020 (+mmu) in fpga instead? should give enough benefits without the complexity?

This is going to sound crazy after my previous rant... but probably the best idea is to clone something more like a Coldfire compatible core on FPGA... but one where all incompatible (with the 68k) instructions/addressing modes are trapped and trigger exceptions. And one where the supervisor mode functions as the supervisor mode on the 68k.

I expect the Freescale engineers carefully selected which 68k features would scale well, and/or be easy to implement simply. Then all less scalable features could be emulated (a la 68060.library etc...), that would not be particularly quick for old software, but it would run (possibly faster than on a real 68k).

If we took TobiFlex's 68k and stripped it back, it could probably be done... and would reduce the complexity/size of the core!

[Donar]

It is possible to configure the CF68klib so that it sets up a Virtual 68k on the Coldfire (with e.g. 68060 as target), but then FPU and MMU will not work and it can not execute Coldfire Code anymore. Would it be possible to place the MMU and FPU in an FPGA'ed ChipSet?

[bloodline]

Donar wrote:
It is possible to configure the CF68klib so that it sets up a Virtual 68k on the Coldfire (with e.g. 68060 as target), but then FPU and MMU will not work and it can not execute Coldfire Code anymore. Would it be possible to place the MMU and FPU in an FPGA'ed ChipSet?

I don't understand the question. The coldfire is not suitable to the amiga... I would hate the think how complex an FPU in an FPGA would be!

[Donar]

I don't understand the question. The coldfire is not suitable to the amiga...

The Coldfire can behave like an 680x0 without MMU and FPU, if you build the right CF68klib from MicroAPL which then sets up a Virtual Machine on the CF. At least that is what the CF68klib manual says.

Problem would be:
Getting the CF on the Amiga Bus.
I think you need an MMU for setting this kind of extension up.
No FPU support.

I would hate the think how complex an FPU in an FPGA would be!

Ok thanks, it was just an idea for a work around for some problems.

[shoggoth]

Donar wrote:

I don't understand the question. The coldfire is not suitable to the amiga...

The Coldfire can behave like an 680x0 without MMU and FPU, if you build the right CF68klib from MicroAPL which then sets up a Virtual Machine on the CF. At least that is what the CF68klib manual says.

Almost. Some instructions cannot be emulated, since they behave differently in the ColdFire. That's what the CF68klib manual says.

Problem would be:
Getting the CF on the Amiga Bus.
I think you need an MMU for setting this kind of extension up.
No FPU support.

You don't need an MMU to get the CF68klib up and running. It uses the illegal instruction vector to implement missing instructions.

[Hammer]

x86s will stay on the desktop,

Laptop PC's dominance is assimilating some embedded type usage e.g. HD-DVD/Blu-Ray/TV portable players,

Btw, Toshiba's HD-A1 HD-DVD player uses Intel's Pentium IV.

simply because if you wish to use an embbedded PC, it is cheaper to buy a common mobo and use it, like ATMs and arcades do.

X86 (Lintel(e.g. LAMP*), Wintel(e.g. WAMP**)) also dominates the 1-way/2-way/4-way server market.

*Linux, Apache, MySQL, Php.
**Windows, Apache, MySQL, Php.

and we will have faster PPCs due to the supercomputer guys (check IBM, for example...)

The reason why BlueGene is *fast* is due to the number of cores involved.

Anyway, in Nov 2007 top 10 supercomputer list
http://www.top500.org/lists/2007/11#top10
1. IBM POWER based.
2. IBM POWER based.
3. Intel Xeon (Core 2) X64 based.
4. Intel Xeon (Core 2) X64 based.
5. Intel Xeon (Core 2) X64 based.
6. AMD Opteron(K8) X64 based.
7. AMD Opteron(K8) X64 based.
8. IBM POWER based.
9. AMD Opteron(K8) X64 based.
10. IBM POWER based.

As you can see, there’s a mix of X86(X64) and POWER based supercomputers.

Cells will go embbeded also,

Toshiba's CELL based SpurEngine doesn't have PPE core. The Toshiba's SpurEngine (as in the demo) uses Intel's Core 2 as it's host CPU instead of PPE.

It’s possible to built a CELL based system, with X86(X64)+SPUs+NV GPU (e.g. Toshiba'a 17" demo laptop) instead of PPE+SPUs+NV GPU(e.g. PS3).
 

[PulsatingQuasar]

Why do you people constantly get back to this discussion. Please read the other threads.

There is already a ColdFire solution and it's called the Dragon from Elbox. It's running and it has been demoed.

The fact we can't buy it is more than likely because they still have problems with it. Probably both on the performance front and compatibility front.

I don't see anyone making this working in their spare time. This is the realistic prediction. Everything else just borders on naive optimism.

The only solution is that Freescale lowers the price of the 68060 they still sell. Hell, lower the price, put it on a smaller die and clock it up!!! OK, thats also not going to happen. Were screwed.

[Donar]

Almost. Some instructions cannot be emulated, since they behave differently in the ColdFire. That's what the CF68klib manual says.

If i read page 10 onward of the manual correctly, which is about "Supervisor mode", that is only true for a CF68klib build for "User mode" :-P

You don't need an MMU to get the CF68klib up and running. It uses the illegal instruction vector to implement missing instructions.

I was told that you need the MMU for setting up an expansion card for the Amiga with eg 68060 or CF. That's why i was nosy about having an MMU in the ChipSet.

[bloodline]

Donar wrote:

Almost. Some instructions cannot be emulated, since they behave differently in the ColdFire. That's what the CF68klib manual says.

If i read page 10 onward of the manual correctly, which is about "Supervisor mode", that is only true for a CF68klib build for "User mode" :-P

There are situations where the Coldfire returns a different result, from what the 68k would return in the same situation. These are not trapped with an illegal instruction vector, and thus cannot be emulated.

Supervisor mode is totally different.

You don't need an MMU to get the CF68klib up and running. It uses the illegal instruction vector to implement missing instructions.

I was told that you need the MMU for setting up an expansion card for the Amiga with eg 68060 or CF. That's why i was nosy about having an MMU in the ChipSet.

MMU and FPU are not required for Amiga.

[Donar]

As i do not know how to explain it properly i take this rather lenghty cut&paste. Sorry for the inconvenience...

User Mode Library
In this form CF68KLib will install its own handlers for the 'Illegal Instruction' and 'Address Error' exceptions which can occur when unimplemented 680x0 instructions are executed on ColdFire. These handlers will perform the same
function as the missing instruction and then return execution to the instruction which follows. The existence of CF68KLib is thus transparent to your application code except that it can incur a substantial performance penalty.

It is occasionally necessary to make minor modifications to your 680x0 program before it can be run under CF68KLib. This is because there are a very small number of 680x0 instructions which are also legal in ColdFire (and hence do not cause an exception) but which do not behave identically. As an example, the MULS instruction executes identically under ColdFire except that it does not set the Overflow flag in the condition codes register.

Ok this is what everybody is always talking about.

Supervisor Mode Library
The ColdFire supervisor model is very different to the 680x0. For example there is only one stack pointer instead of separate User and Supervisor stacks, and the format of an exception stack frame is different. This means that although instructions such as TRAP and RTE are implemented in the ColdFire architecture, a 680x0 binary such as an operating system would be unlikely to work correctly. For this type of problem you can use the Supervisor Mode form
of CF68KLib. In the Supervisor Mode form, the CF68KLib library takes over the handling of all ColdFire exceptions in order to implement a complete 680x0 virtual machine.
The presence of CF68KLib is transparent to your 680x0 code, which 'thinks' it is running on a real 680x0 processor, and you can run an entire 680x0 operating
system including interrupt-driven hardware inside the virtual machine. Because the Supervisor Mode form of CF68KLib has to take over the handling of all ColdFire exceptions it is generally not possible to use this form of the library alongside a native ColdFire operating system, although you can still execute application-level ColdFire code.

No problems with the different supervisor mode model, as the 68k one is emulated. And as it is not mentioned otherwise (as it is on the paragraph about user mode) it seems that also the differently implemented CF/68k instructions return the proper result!?

If you wonder where i pulled that from:
Click

[bloodline]

@Donar

Yes exactly!

The MUL problem would kill a large amount of Amiga Code. Code which we can't modify, as CF68KLib suggests, because we don't have the source code.

 Supervisor mode would be very slow...

The point is not that the Coldfire can't be used... the point is that the amount of work required would be the same for any CPU... and there are cheaper faster ones available!

[shoggoth]

If i read page 10 onward of the manual correctly, which is about "Supervisor mode", that is only true for a CF68klib build for "User mode" :-P

Donar, had you read the documentation properly you'll also know that not all instructions can be trapped and emulated. :-P :-P :-P :-P :-P

Read the ColdFire reference documentation and/or chapter 5 in the CF68KLib docs.

I was told that you need the MMU for setting up an expansion card for the Amiga with eg 68060 or CF. That's why i was nosy about having an MMU in the ChipSet.

Well, I don't know about that, but I do know that CF68klib in itself doesn't need an MMU to get up and running.

[Krusher]

The A3000 with a 1.4 rom needs the '030 mmu, so yes it's used.

Kickstart V1.4 is actually a special version of Kickstart which loads the real Kickstart from a file called DEVS:Kickstart. Kickstart V2.04 was available as a ROM, or as a disk based version for use with A3000's which had Kickstart V1.4. A3000's fitted with Kickstart V1.4 cannot use 040 or 060 processors, regardless of what version of Kickstart is eventually booted, because it relies heavily on the integrated MMU in the 030 which varies to some degree from the MMU in 040 and 060 processors.

From the Big book of Amiga Hardware.

[shoggoth]

No problems with the different supervisor mode model, as the 68k one is emulated. And as it is not mentioned otherwise (as it is on the paragraph about user mode) it seems that also the differently implemented CF/68k instructions return the proper result!?

CF68KLib can only emulate instructions which are trapped by the ColdFire. If the instruction in question doesn't cause and illegal instruction, it won't be trapped, hence not emulated. User Mode or Supervisor Mode library doesn't matter.

Are you a coder, Donar?

[AeroMan]

Hammer wrote:

X86 (Lintel(e.g. LAMP*), Wintel(e.g. WAMP**)) also dominates the 1-way/2-way/4-way server market.

Agree. But as I've said, those machine are PCs anyway, not fully custom hardware with a x86 at its core

The reason why BlueGene is *fast* is due to the number of cores involved.

Maybe you misunderstood my point of view. I was not stating that all supercomputers use PPC. What I mean is that althrough Apple does not have PPC Macs anymore, the architecture will not die, because those supercomputer companies have interest in pushing its development further.
IBM is going to Power 6.
Blues Gene may be faster because it has more cores, but speed needs will grow, and using even more cores won't be feasible at some point. The cores will have to go faster, and they know that (this is the reason why nobody is using a box with zillions of Z80s :-D )
Home PCs market will keep pushing x86s faster also, but a quick solution would be use more cores. One could think in the reverse way and say x86 development could stop because we would have faster machines with more CPUs. (of course, this is nonsense...)

Cells will go embbeded also,

Again, I think you misunderstood me. What I mean is that CELLs will be in available microcontrollers soon, as PPCs are today. I bet your car has at least one PPC. Some years ago, PPCs were heavy weight processors.  When I've started working with EFI modules, companies used 68HC11s or 8051s derivatives. Engines didn't changed that much in that amount of time, but ECUs now have those beasts calculating when to fire the spark and how much fuel to burn.
I don't believe the industry will stay comfortable with with today's processing capabilities, so I believe it is a matter of time before your microwave oven have a CELL, and this chip will cost then 5 bucks maybe.
If it makes you feel better, probably you may have a 5 bucks Pentium 4 some time in future also.

Shouldn't we be talking about Coldfires instead ??

[Donar]

User Mode or Supervisor Mode library doesn't matter.

I only find it strange that in the user mode paragraph it is mentioned explicitly that the differently implemented instructions will not work, and in the supervisor mode paragraph there is no word about it. It sounds like the library will set up an full 680x0 Emulator (without MMU/FPU) on the Coldfire but maybe i interprete in the text what i want to be true :lol:  

Are you a coder, Donar?

No, but i think i can read...  :-)