8052 emulator in C

In message , joolzg writes

The Keil simulator already has that. You won't need to modify it.

Then use the Keil simulator that already has the support.

Why spend a lot of time and energy (== money) on re-inventing the wheel?

In message , joolzg writes

Yes. AFAIK

Also any code needed will be via the two well documented interfaces on the sim.

BTW if it is 8051 code it is an 80% chance wit was written using the Keil system... For non-standard 8051 types the likelihood is over 90% that the Keil system was used.

In message , joolzg writes

You are both correct and completely wrong.

The original 8051 is an old design. However there are well over 60 different cores for the family with very different timing models (not to mention memory maps and SFRs) Most 8051 types are NOT based on an Intel core. The one you are using most certainly is not.

Yes the simulator for the 8051 family is easy to find... over 80% of the

Particularly for the unusual cores such as this one where a "standard"

Hmmm, Sounds like you agree with that statement.

Reverse engineering can be done in many ways, not just looking directly at the code.

hamilton

The 6303 I remember was the Hatichi HD6303, it was a CMOS replacement for the Motorola 6803.

hamilton

It wasn't clear to me what you meant by "impossible".

Some languages - e.g. Java, C#, VB, etc. - which compile to canonized byte code and carry meta-information in the binary can be decompiled nearly perfectly.

In the general case of a HLL compiled to assembler, it is possible to recover the compiler's generated template code ... however that may not match up with the source.

for example, on most CPUs a backward conditional branch is faster than a forward conditional branch ... so virtually any kind of loop will be rearranged so that the exit test is at the end. So given the following C code:

for ( i = 25; i

But there isn't any need unless acquiring a existing simulator will blow the budget. Good simulators all are extensible so I/O and non-standard devices can be emulated.

George

Like the PDP-8?

While Cain's compiler wasn't *commercial*, it illustrates the type of "mechanical replacement" of C statements with assembly language stanzas that I was talking about.

Here's a toy bit of code run through the Small-C compiler with the C source interspersed. Note that even on this tiny bit of code, you can see how the compiler "thinks" (note the metric butt-load of "helper routines" -- CC* --invoked!):

---------8

In message , George Neuner writes

The entire Keil 8051 development suite costs less than a weeks work. You will not create a simulator including peripherals for an ADuC84* in that time. So the Keil simulator is very cost effective.

There are few simulators of that calibre. Added to which it is a 90% chance the original system was written using the Keil system.

Often that depends on whether the tools budget and the time budget are fungible. I've worked plenty of places where that's not true.

Yes. Where the hassle involved in getting approval of a few kilobucks just isn't worth it! "What the heck... let them spend the dollars on my salary, instead. It's *their* money. If they think this is the best way to spend it, "

Or, where you expect to *go* with the tool after you have it. E.g., if stops supporting upon which a good part of your business depends, you can find yourself SoL in short order.

Or, if doesn't want to add to (for any "realistic" amount of money -- perhaps because he doesn't want to assume the responsibility of supporting in perpetuity) and that has some significant value to you.

Lastly, having that IP has some intrinsic value. E.g., when putting your own core on an ASIC -- even *rolling* your own core! -- is NoBigDeal, nowadays, being able to have a simulator for *that* core available in short order can be a real win.

It's also possible the OP hasn't made clear *all* of his/her decision criteria... ;-)

Hmm. I've worked with a number of simulators that were extensible. One even had a scripting language but the others provided a C language API for extending the model with dynamic libraries.

I will stipulate that these all were for (far) more modern chip families. I haven't worked much in very small systems and it's been many years since last I used one of Kiel's simulators.

I would have thought they would be caught up, but perhaps not. George

Precisely - That was a common approach at the time, used by PDP-8s, Novas, HP-1000/2000s etc. I believe the same applies to IBM 360s.

-- Roberto Waltman

The IBM 360 and descendants put the return address into a general register specified in the call (BAL or BALR). The return is performed with a register-indirect branch.