8052 emulator in C

In my case, these were PC based tools. The only compilers I had access to on the MDS were silly things like PL/M (which, actually, was *an* improvement)

I think the problem from that timeframe (mid 80's, in my case) was a combination of things:

- targets were pretty crippled. They really weren't designed with HLL's in mind (with the exception of the bigger 16/32 bit machines). E.g., support for stack frames was tedious at best. And, even then, limited (e.g., "index registers" with +- 128 byte offsets)

- there were *lots* of different processor *families*. 6800/3/5 6809, 68HC11, 8080/85/Z80/Z180, Z8000, 68000, 9900, 99000, 1802/5, 6502/816, 2650, 8x300, etc. With no single market leader. A "compiler vendor" was almost forced to try to address *all* of these targets to increase the chance for a sale. So, you ended up with a core compiler and varying backends.

- the PC was becoming a viable development platform (previously, we used CP/M boxes or vendor supported "development systems"). So, you had lots of folks putting forth products to try to sell to that "development system". Almost all were "command line" driven tools, no IDE's, etc.

- users were anxious to get their hands on *anything* that could expedite development. ASM was just *painfully* slow for bigger projects.

- resources were starting to become affordable. The $50 2KB EPROMs were a thing of the past. And, you could actually think of putting more than a few *hundred* bytes of RAM into a system!

Cool! From this, you could probably port to a 68K disassembler with little trouble. Or even a 32K.

Exactly. The compiler tends to do the same thing, the same way. It's hard for "hand-written" code to achieve that same level of discipline.

Have you looked at some of the code compiled for PICs?

You know, given the OP's apparent need to modify "whatever" to accommodate the peculiarities of his situation, this is probably the *best* (quickest to having something "useful") answer!

Even IRQs and peripherals could be hacked in -- if you *don't* need it to be fast!

it would be a great "school project" to show how a processor works and how to write "boilerplate" code (to implement the machine).

My favorite example of obvious but missed optimization was a Fortran compiler for HP-1000 minis, that would always generate a return instruction at the end of a function even when the last statement was RETURN.

(OK, for purists, the "return" instruction was an indirect jump through the first word of the function, lets call it JUMPBACK for now)

so,

FUNCTION xxx ... END

would generate a bunch of instructions ending in ... JUMPBACK

while this,

FUNCTION xxx ... RETURN END

would generate a bunch of instructions ending in ... JUMPBACK JUMPBACK

To hamilton, Yes - For "simple minded" compilers you can reverse generate code that is very close to the original. This FORTRAN compiler was very predictable, but I doubt you can find a Hewlett-Packard RTE-II system running it. You may try Ron Cain's original Small-C compiler for the 8080.

-- Roberto Waltman

[ Please reply to the group. Return address is invalid ]

I know what the SDCC does and I know what the ADuC84* is.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Actually, fast run-time is not /that/ hard either - you just have to separate the "interpret" phase from the "run" phase, and have the "interpret" phase generate C code equivalent to the disassembly (i.e., when you see an instruction "add a, b", you write out the line "regs.a

+= regs.b". The joy is getting the flag registers right, and perhaps the timing, and including some way for interrupts to jump in. In the end, you have a humongous C function with a few lines per original disassembly line. Run that through your host compiler, and your 8052 runs at a few hundred MIPS.

AFAIR the ADuC84* is not a standard 8052 core and neither are the peripherals or memory map.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

I was thinking of this more from the standpoint of debugging code in an IDE... "step, step, run-to-here, examine registers, etc.". I.e., if the OP doesn't know what the code *does*, I would think he would want to watch it work and *see* what it is doing instead of just hoping to catch some "results" in a "console window", etc. (i.e., how would you know what to feed it if you can't see what it is expecting).

I understand extra peripheral registers added by a vendor to there 8052 core, but the base core registers should be the same, no?

hamilton

Either your professor was mistaken or you misunderstood.

The point of decompiling is not to recover the original code, but rather simply to get something that's easier to work with than an assembler listing.

You can reverse engineer the output of any compiler. However, the best you can achieve is /equivalent/ source to that which was originally compiled. Only for very simple programs can anything looking like the original source be recovered.

Compilers generate code from templates - each construct in the source language is mapped to one or more sequences of assembler that are strung together to realize the construct. Once you learn the patterns generated by your compiler, many source language constructs are easily identifiable in /unoptimized/ assembly.

Certain optimizations make things a lot harder. Inline expansion, loop and function fusion and others can modify the code so that patterns and boundaries visible in the original source no longer are recognizable. However, the ordering of data dependencies has to be maintained (otherwise the optimizer is broken), so by identifying these dependencies and constructing chains of dependent operations, you can always work backwards to a sequence of source language code that will produce equivalent results.

This is how decompilers work. There are a number of them available for various languages.

George

This would make the idea of writing a simulator himself more appealing - it doesn't matter how standard or non-standard it is, as long as it is documented.

There is a bit more to it than that. For a start it is not a standard

8052 core and it is a single cycle core which will make all the timing very different. A simulator is not real time but it does have to synchronise all parts of the simulation.

Also the simulation of the peripherals will take some doing.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message , David Brown writes

The idea ay be appealing bit if the OP has a job to do why waste so much time and resources re-inventing the wheel?

There is a very good 8051 sim available that is supported by AD that will simulate the part very well (that has a serial window) and well documented interfaces that permit adding to the peripheral support.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In reply to " snipped-for-privacy@kapsi.spam.stop.fi.invalid" who wrote the following:

Sorry had a quick look and delphi was mentioned, i went back and downloaded the source, also found a couple more on the web and ended up using ucsim

joolz

--
--------------------------------- --- -- -
Posted with NewsLeecher v5.0 Beta 6
Web @ http://www.newsleecher.com/?usenet
------------------- ----- ---- -- -

In reply to "Chris H" who wrote the following:

Hence the reason for wanting source so i can modify it to take in the special features of the chip and also the interfaces.

Ive got ucsim running now under command line and i am now optimising the code, need more speed and adding in things like serial in/out and the interface devices.

thanks for the help

joolz

--
--------------------------------- --- -- -

In reply to "Walter Banks" who wrote the following:

Bugs in code, no source code available any more, its a job for a friend and i have been doing this work as a job for over 20 years, my first was a re-assembler for the C64 for a games company i worked for.

I have lots of experience in this but just needed a 8052 sim.

last job was a ARM decoder and annotate so this little chip will be a lot easier.

joolz

--
--------------------------------- --- -- -

In reply to "David Brown" who wrote the following:

Yep and then the debugging od the cpu to make sure it is correct, as this is an old processor i did think it would be easy to find a sim

as before i found ucsim so working on it now

joolz

--
--------------------------------- --- -- -
Posted with NewsLeecher v5.0 Beta 6
Web @ http://www.newsleecher.com/?usenet
------------------- ----- ---- -- -

In reply to "D Yuniskis" who wrote the following:

You missed one of my old favorite cpus, 6303 a 4bit processor, i wrote the firmware for a mouse on that.

Also ive just finished 3 projects on a PIC18f4550 and using the Hi-TECH PRO compiler, code is ok and runs

joolz

--
--------------------------------- --- -- -
Posted with NewsLeecher v5.0 Beta 6

In reply to "Chris H" who wrote the following:

Ok so can you simulate 3 I2C devices [secure eeprom, temp sensor and IR convertor], 1 spi flash, 3 serial ports and 4 ir led drivers, without writing any code?

joolz

--
--------------------------------- --- -- -
Posted with NewsLeecher v5.0 Beta 6
Web @ http://www.newsleecher.com/?usenet
------------------- ----- ---- -- -

In reply to "David Brown" who wrote the following:

I did a 6805 to pic conversion the exact same way, had a bit include file for #define for all the instructions, my only sticking point was the interrupt driver was cycle based for writing data to another device so that had to be hand written to get it cycle exact, but it ran so everybody was happy and their asm old 6850 was not running on a pic in c

joolz