Last visit was: Wed May 22, 2024 6:06 pm
It is currently Wed May 22, 2024 6:06 pm

 [ 4 posts ] 
 Simulation opcodes 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Any processors reserve opcodes specifically to support a simulator or emulator ?
The opcode would be executed by the simulator but not by the processor.
One that comes to mind is 'stop' or 'end' simulation.

Robert Finch

Thu Feb 21, 2013 12:09 am WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
robfinch wrote:
The opcode would be executed by the simulator but not by the processor.
One that comes to mind is 'stop' or 'end' simulation.
I think I follow you but it's hard to be certain. Can you expand a little -- flesh out the scenario, please? And, regarding terminology, the "simulator" is the software that runs on the host processor, correct? Still, I don't see that 'stop' and 'end' opcodes would be required. The simulation is essentially a loop that's running, and termination would simply require a conditional branch to exit the loop -- or am I missing something?

As an aside, this is a topic that reminds me of Transmeta's "Crusoe," which was a Very Long Instruction Word processor designed to execute x86 code that had been "code morphed" at runtime! That is, x86 object code would be examined at run time by the VLIW processor, translated on the fly into native code, then executed by the VLIW cpu. The quality of translation was variable, defaulting to simple, substitution-based translations that could be produced very rapidly. But if an x86 program "hot spot" such as a loop was detected, the priority would shift and the code morphing software (CMS) would invest extra time in producing an optimized translation that executed with maximum efficiency. IIRC this meant a wider scope, looking at groups of x86 instructions to find opportunities for optimization. To some extent there's a parallel between what the CMS does in software and what modern, out-of-order, superscalar CPUs do in hardware.

According to
Transmeta claims several technical benefits to this approach:

1. As the market leaders Intel and/or AMD would extend the core x86 instruction set, Transmeta could quickly upgrade their product with a software upgrade rather than requiring a respin of their hardware. This method just emphasises the compatibility rather than the performance.
2. Performance and power can be tuned in software to meet market needs.
3. It would be relatively simple to fix hardware design or manufacturing flaws in the hardware using software workarounds.
4. More time could be spent concentrating on enhancing the capabilities of the core or reducing its power consumption without worrying about 33 years of backward compatibility to the x86 architecture.
5. The processor could emulate multiple other architectures, possibly even at the same time. (At its initial Crusoe launch, Transmeta demonstrated pico-Java and x86 running intermixed on the native hardware.)


Fri Feb 22, 2013 3:29 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Transmeta has an interesting idea. I believe they were interested in low power operation for things like laptops.

the "simulator" is the software that runs on the host processor, correct?

Yes, the simulator runs on a host processor. A simluator often has numerous commands like $stop or $display (in Verilog) which the simulator executes, but the target processor doesn't. What I'm wondering is if there are any processors that support simulator command opcodes embedded in code. Suppose there was a 'dump registers' command in the simulator. In the simulated code one might have the command '$dumpregs' embedded, this code of course does not end up in the code the target processor runs.

Opcodes reserved for the simulator could be used for breakpoint positions on the target system. Or they could be used to emulate the simulator functions on the target hardware. Exactly why one would want to, I'm not sure.

Not exactly sure what I'm thinking of here. I'm just curious if something like this has been done.

Robert Finch

Sun Feb 24, 2013 9:29 pm WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1786
It's not quite what you're asking for Rob, but in my 6502 emulator for ARM I grabbed a couple of the 0x42 (WDM) operations to perform I/O:

I suspect I'd do the same for a novel CPU: use whatever unimplemented or reserved opcodes came to hand. In which case your question comes down to whether anyone did that and documented it. I'm not aware of any such document, but that says very little.


Mon Feb 25, 2013 12:42 pm
 [ 4 posts ] 

Who is online

Users browsing this forum: CCBot and 0 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software