But compatible.


You are not getting the point of compatibility being useless if the machine is too slow to run the code it can now run. It's like porting a DVD player back to a 486... It will never work anyway, so who cares if the 486 can actually run the code or not?

I don't want to buy a Prescott to be able to write Prescott code


Why don't you create SSE3 macros then, and use those in your code, so that they get translated directly, without any recompilation or other overly complex nonsense? Ultimately you will need a Prescott ofcourse, because there's no other way to verify your macros/code.
Posted on 2004-06-06 12:12:33 by Scali
f0dder the turning off the cache was a trick for making 286 games playable on the 486!
I've still got a little app that did it on my old 486, it came with Wing commander 2 IIRC.

On the original topic, the ARM linux does something like this in the kernel to support the floating point module not present on certain classes of the ARM core. I'm not entirely sure where you'd need to look in the code, but I know it's there (it doesn't work properly for sine & cosine functions on the ARM)!.

The cost in any given individual program would vastly outweigh the portability aspect, especially with SSE as they are a performance instruction set... Putting them in a driver would be a "nice" failsafe, but any programmer who uses SSE without checking that it's available deserves to be taken out and shot.

Mirno
Posted on 2004-06-06 16:06:24 by Mirno

You are not getting the point of compatibility being useless if the machine is too slow to run the code it can now run. It's like porting a DVD player back to a 486... It will never work anyway, so who cares if the 486 can actually run the code or not?

Think more about running Prescott code on a Northwood core. The DVD will play. I wouldn't care if it's only one frame per second. And it might not be existing instructions I want to emulate. :cool:
Why don't you create SSE3 macros then, and use those in your code, so that they get translated directly, without any recompilation or other overly complex nonsense? Ultimately you will need a Prescott ofcourse, because there's no other way to verify your macros/code.

Sure, I can write macros. But it might not be my own code that needs 'emulation' support...

Never question the question. ;)
Posted on 2004-06-06 18:13:58 by C0D1F1ED
If not enough information is provided to start with, you have to 'question the question' to find an optimal solution...

So, you want to run other peoples binaries, to which you don't have the source - (or you want to produce a product that allows other people to do this). If this is it, you'll need to set up an emulation/JIT system... and if you want performance that's even remotely acceptable, you'll need a good JIT...
Posted on 2004-06-06 18:21:55 by f0dder
The DVD will play. I wouldn't care if it's only one frame per second.


Nobody is going to watch a DVD at 1 frame per second.
Much better to write decent code for Northwood then.

And it might not be existing instructions I want to emulate.


Yea! Let's all invent our own instructionsets and emulate them! You need a new hobby?
Posted on 2004-06-06 18:38:19 by Scali

You need a new hobby?
`
Yes, I still got four hours of sleep every day. :grin:
Posted on 2004-06-07 15:22:33 by C0D1F1ED
I dont know how runtime Softwire really is, but how about using cpuid to see if the users system even supports SSE? Then if SSE is used, provide a same functioning alternative. This reduces the amount of checks for invalid opcodes you need to 1, at Softwire initiliaztion.
Posted on 2004-06-07 19:12:51 by ThoughtCriminal
TC, he said he might want to emulate for other people's programs too, to which he doesn't have source... ie, a generic system-level emulator... as far as I understand it, anyway.

Scali, take it easy?
Posted on 2004-06-07 19:18:04 by f0dder
Yes I understand that it is for other peoples programs.

What I'm saying is use cpuid to get to get the the system spec it is running on. What if someone runs a program that uses MMX or SSE and their processor does not support either?

Maybe I'm misunderstanding how Softwire works, just how real-time it is. Can it emit code and excute it right after being emitted?

What I'm saying is that once you know what the running system supports, even thought the code may contain MMX or SSE, can it at runtime patch that code to plain fpu or equivilent x86 while it is running? Or a first run patch?
Posted on 2004-06-08 00:28:13 by ThoughtCriminal