On 5/26/2011 12:14 AM, joolzg wrote:> In reply to "D Yuniskis" who wrote the following: >> - there were *lots* of different processor *families*. 6800/3/ >> 6809, 68HC11, 8080/85/Z80/Z180, Z8000, 68000, 9900, 99000, 1802/5, >> 6502/816, 2650, 8x300, etc. With no single market leader. >> "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.> You missed one of my old favorite cpus, 6303 a 4bit processor, i wrote the > firmware for a mouse on that.IIRC, the 6303 was a 6803 (and 6301 was 6801). They'd be called "8 bit" processors even if their internal ALU was only 4b wide. I lump all of them in the "680x" category (the '09 and hc11 deserve slightly better attention) I.e., the i4004 was one of the few 4 bitters (IIRC, the TMS1000 and TLCS47 were equally crippled).
8052 emulator in C
Started by ●May 24, 2011
Reply by ●May 26, 20112011-05-26
Reply by ●May 26, 20112011-05-26
In message <4dddfc92$0$2312$c3e8da3$5b14842f@news.astraweb.com>, joolzg <joolzg@btinternet.com> writes>In reply to "Chris H" who wrote the following: > >> In message <4ddcbb4c$0$1469$c3e8da3$fb483528@news.astraweb.com>, joolzg >> <joolzg@btinternet.com> writes >> > In reply to "Chris H" who wrote the following: >> > >> > > In message <4ddb6833$0$1509$c3e8da3$efbdef2c@news.astraweb.com>, joolzg >> > > <joolzg@btinternet.com> writes >> > > > Anybody got a simple 8052 emulator in C source, im trying to reverse >> > > > engineer >> > > > some code and would like to emulate/simulate the code to get a better >> > > > understanding as it looks like it was written in C and compiled by a >> > > > very >> > > > bad >> > > > compiler >> > > >> > > What is the target MCU? The 51 family is huge (over 600 variants) and >> > > whilst the cores are similar there are some big differences. >> > > >> > Analog Devices ADuC84x >> >> This is NOT a true 8051/52 core. Read the documentation it is "based >> on" an 8052. Not all they 8051 simulators will handle the non standard >> 8051 parts like this one. >> >> > > Why do you want the source of the simulator? >> > > >> > So i can add in a serial driver, also the output display, you know make the >> > simulator behave like the real thing with inputs and outputs >> >> Then use the Keil Simulator that can do this already. >> >> >> > > How do you know the binary was written in C? >> > I can tell from the way the code is written!! cant you tell the differnece >> > between human and machine created code >> >> Yes... However you can not tell which HLL was used. >> >> > > How big is the binary? >> > 64k but not all used >> >> > > What is it supposed to do? >> > cant say >> >> Use the Keil Sumulator. > >Hence the reason for wanting source so i can modify it to take in the special >features of the chip and also the interfaces.The Keil simulator already has that. You won't need to modify it.>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.Then use the Keil simulator that already has the support. Why spend a lot of time and energy (== money) on re-inventing the wheel? -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●May 26, 20112011-05-26
In message <4dddfea4$0$2312$c3e8da3$5b14842f@news.astraweb.com>, joolzg <joolzg@btinternet.com> writes>In reply to "Chris H" who wrote the following: > >> In message <irjg31$mee$1@speranza.aioe.org>, Anders.Montonen@kapsi.spam. >> stop.fi.invalid writes >> > Chris H <chris@phaedsys.org> wrote: >> > > In message <irhc0q$p5d$1@speranza.aioe.org>, Anders.Montonen@kapsi.spam. >> > > stop.fi.invalid writes >> > > > joolzg <joolzg@btinternet.com> wrote: >> > > > > Anybody got a simple 8052 emulator in C source, im trying to reverse >> > > > > engineer some code and would like to emulate/simulate the >> > > > >code to get >> > > > > better understanding as it looks like it was written in C and >> > > > > compiled >> > > > > by a very bad compiler >> > > > There's the Daniel's s51 simulator[1] which is used in the SDCC[2] >> > > > debugger. >> > > I doubt it will work. >> > >> > Of course you do. >> >> I know what the SDCC does and I know what the ADuC84* is. >> > >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?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. -- Support Sarah Palin for the next US President Go Palin! Go Palin! Go Palin! In God We Trust! Rapture Ready!!! http://www.sarahpac.com/
Reply by ●May 26, 20112011-05-26
In message <4dddfd4e$0$2312$c3e8da3$5b14842f@news.astraweb.com>, joolzg <joolzg@btinternet.com> writes>In reply to "David Brown" who wrote the following: > >> On 24/05/11 10:11, joolzg wrote: >> > Anybody got a simple 8052 emulator in C source, im trying to reverse >> > engineer >> > some code and would like to emulate/simulate the code to get a better >> > understanding as it looks like it was written in C and compiled by a very >> > bad >> > compiler >> > >> > joolz >> > >> >> It shouldn't be too hard to write a simulator yourself for a processor >> like this. It's quite an effort if you want it to be fast, or to >> accurately simulate interrupts and peripherals, but the core itself is >> easy - you have an array to hold "ram", and array for "flash", a struct >> holding the registers, and a huge switch statement interpreting each >> instruction. > > >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 simYou 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 8051 world uses www.keil.com Particularly for the unusual cores such as this one where a "standard" 8051 simulator will not work. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●May 26, 20112011-05-26
On 5/25/2011 11:22 PM, George Neuner wrote:> On Tue, 24 May 2011 13:46:31 -0600, hamilton<hamilton@nothere.com> >> >> I took a compiler class 30 years ago, and my professor at the time >> stated that it was not possible. >> With the better compiler available today it would be even more impossible. > > 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.Hmmm, Sounds like you agree with that statement. Reverse engineering can be done in many ways, not just looking directly at the code. hamilton
Reply by ●May 26, 20112011-05-26
On 5/26/2011 1:14 AM, joolzg wrote:> > You missed one of my old favorite cpus, 6303 a 4bit processor, i wrote the > firmware for a mouse on that.The 6303 I remember was the Hatichi HD6303, it was a CMOS replacement for the Motorola 6803. hamilton> joolz > > >
Reply by ●May 26, 20112011-05-26
On Thu, 26 May 2011 10:11:01 -0600, hamilton <hamilton@nothere.com> wrote:>On 5/25/2011 11:22 PM, George Neuner wrote: >> On Tue, 24 May 2011 13:46:31 -0600, hamilton<hamilton@nothere.com> >>> >>> I took a compiler class 30 years ago, and my professor at the time >>> stated that it was not possible. >>> With the better compiler available today it would be even more impossible. >> >> 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. > >Hmmm, Sounds like you agree with that statement. > >Reverse engineering can be done in many ways, not just looking directly >at the code. > >hamiltonIt 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 <= 73; ++i ) { : } or i = 25; while ( i <= 73 ) { : ++i; } a great many compilers will rearrange either loop into the equivalent: i = 25; if ( i > 73) goto END_LABEL; :START_LABEL : ++i; if ( i <= 73 ) goto START_LABEL; :END_LABEL and then generate assembler to implement it. A decompiler can fairly easily recover this kind of stylized code, which itself is easily recognized by a programmer as a do-while loop with a preceding skip test. A programmer seeing this should know (but not care) that the original source might actually have been a for or a while loop. A good decompiler might actually output the do-while loop rather than the labeled goto version. My point simply is that it is always possible to work backward from assembler to an equivalent sequence in the HLL, and equivalency is sufficient to recover algorithms from the original code. George
Reply by ●May 26, 20112011-05-26
On Thu, 26 May 2011 08:13:47 +0200, David Brown <david.brown@removethis.hesbynett.no> wrote:>On 25/05/11 23:09, Chris H wrote: >> In message<1ZGdndkNyORi8UDQnZ2dnUVZ7rOdnZ2d@lyse.net>, David Brown >> <david.brown@removethis.hesbynett.no> writes >> >> AFAIR the ADuC84* is not a standard 8052 core and neither are the >> peripherals or memory map. > >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.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
Reply by ●May 27, 20112011-05-27
Hi Roberto, On 5/25/2011 12:23 PM, Roberto Waltman wrote:>> I remember thinking about "peephole optimizers" and wondering how >> they could be effective ("Shirley the compiler knows what code it >> *just* emitted? Why would it ever do something as inane as >> 'STORE X; LOAD X'?"). But, if you saw how stanzas were "pasted" >> together, you could see lots of opportunities for this kind >> of micro-optimization! > > 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)Like the PDP-8?> 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.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<----------8<--------------8<---------------- ;<><><> Small-C V1.2 DOS--CP/M Cross Compiler <><><> ;<><><><><> CP/M Large String Space Version <><><><><> ;<><><><><><><><><><> By Ron Cain <><><><><><><><><><> ; ORG 100H LHLD 6 SPHL CALL CCGO CALL QZMAIN CALL QZEXIT ;#define SUCCESS (0) ;#define FAILURE (27) ;#define LENGTHY "a lot of" ;#define MAX_ATTEMPTS (10) ;main() /* return type & void not supported */ QZMAIN: ;{ ; char x; /* uninitialized */ DCX SP ; int attempts; /* initialiZers unsupported */ PUSH B ; int start, end; PUSH B PUSH B ; char interval[20]; /* >= max( (sprintf(end - start)/attempts, "%f"), sizeof ;LENGTHY) ) */ XCHG LXI H,-20 DAD SP SPHL XCHG ; start = gettime(); LXI H,22 DAD SP PUSH H CALL QZGETTIME POP D CALL CCPINT ; attempts = 0; LXI H,24 DAD SP PUSH H LXI H,0 POP D CALL CCPINT ; while (x = getchar()) { CC2: LXI H,26 DAD SP PUSH H CALL QZGETCHAR POP D MOV A,L STAX D MOV A,H ORA L JZ CC3 ; if (x == 'Q') { LXI H,26 DAD SP CALL CCGCHAR PUSH H LXI H,81 POP D CALL CCEQ MOV A,H ORA L JZ CC4 ; printf("Got X = %x\n", x); LXI H,CC1+0 PUSH H LXI H,28 DAD SP CALL CCGCHAR PUSH H CALL QZPRINTF POP B POP B ; ringbell(); CALL QZRINGBELL ; } ; if (++attempts >= MAX_ATTEMPTS) { CC4: LXI H,24 DAD SP PUSH H CALL CCGINT INX H POP D CALL CCPINT PUSH H LXI H,10 POP D CALL CCGE MOV A,H ORA L JZ CC5 ; printf("Giving up after %d iterations!\n", attempts); LXI H,CC1+13 PUSH H LXI H,26 DAD SP CALL CCGINT PUSH H CALL QZPRINTF POP B POP B ; return FAILURE; LXI H,27 XCHG LXI H,27 DAD SP SPHL XCHG RET ; } ; end = gettime(); CC5: LXI H,20 DAD SP PUSH H CALL QZGETTIME POP D CALL CCPINT ; if (end < start) { LXI H,20 DAD SP CALL CCGINT PUSH H LXI H,24 DAD SP CALL CCGINT POP D CALL CCLT MOV A,H ORA L JZ CC6 ; /* overflow */ ; interval = LENGTHY; LXI H,0 DAD SP LXI H,CC1+46 ; } else { JMP CC7 CC6: ; sprintf(interval, "%f", (end - start) / attempts); LXI H,0 DAD SP PUSH H LXI H,CC1+55 PUSH H LXI H,24 DAD SP CALL CCGINT PUSH H LXI H,28 DAD SP CALL CCGINT POP D CALL CCSUB PUSH H LXI H,30 DAD SP CALL CCGINT POP D CALL CCDIV PUSH H CALL QZSPRINTF POP B POP B POP B ; } CC7: ; printf("There were %d unsuccessful attempts prior to this.\n", attempts); LXI H,CC1+58 PUSH H LXI H,26 DAD SP CALL CCGINT PUSH H CALL QZPRINTF POP B POP B ; printf("with an average interval of %s seconds.\n", interval); LXI H,CC1+111 PUSH H LXI H,2 DAD SP PUSH H CALL QZPRINTF POP B POP B ; ; return SUCCESS; LXI H,0 XCHG LXI H,27 DAD SP SPHL XCHG RET ;} ...
Reply by ●May 27, 20112011-05-27
In message <vuftt6hluba3rp9f9bi40b7t98lo1jbpva@4ax.com>, George Neuner <gneuner2@comcast.net> writes>On Thu, 26 May 2011 08:13:47 +0200, David Brown ><david.brown@removethis.hesbynett.no> wrote: > >>On 25/05/11 23:09, Chris H wrote: >>> In message<1ZGdndkNyORi8UDQnZ2dnUVZ7rOdnZ2d@lyse.net>, David Brown >>> <david.brown@removethis.hesbynett.no> writes >>> >>> AFAIR the ADuC84* is not a standard 8052 core and neither are the >>> peripherals or memory map. >> >>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. > >But there isn't any need unless acquiring a existing simulator will >blow the budget.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.> Good simulators all are extensible so I/O and >non-standard devices can be emulated.There are few simulators of that calibre. Added to which it is a 90% chance the original system was written using the Keil system. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
