Reply by Tauno Voipio May 28, 20112011-05-28
On 28.5.11 10:11 , Roberto Waltman wrote:
> D Yuniskis wrote: > >>> (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? > > 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. -- Tauno Voipio
Reply by Roberto Waltman May 28, 20112011-05-28
D Yuniskis  wrote:

>> (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?
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 [ Please reply to the group, return address is invalid ]
Reply by George Neuner May 27, 20112011-05-27
On Fri, 27 May 2011 09:08:53 +0100, Chris H <chris@phaedsys.org>
wrote:

>In message <vuftt6hluba3rp9f9bi40b7t98lo1jbpva@4ax.com>, George Neuner ><gneuner2@comcast.net> writes > >> 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.
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
Reply by D Yuniskis May 27, 20112011-05-27
Hi Grant,

On 5/27/2011 6:56 AM, Grant Edwards wrote:
> On 2011-05-27, Chris H<chris@phaedsys.org> wrote: >> In message<vuftt6hluba3rp9f9bi40b7t98lo1jbpva@4ax.com>, George Neuner >> >>> 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. > > 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, <shrug>" Or, where you expect to *go* with the tool after you have it. E.g., if <vendor> stops supporting <tool> upon which a good part of your business depends, you can find yourself SoL in short order. Or, if <vendor> doesn't want to add <feature> to <tool> (for any "realistic" amount of money -- perhaps because he doesn't want to assume the responsibility of supporting <feature> in perpetuity) and that <feature> 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... ;-)
Reply by Grant Edwards May 27, 20112011-05-27
On 2011-05-27, Chris H <chris@phaedsys.org> wrote:
> In message <vuftt6hluba3rp9f9bi40b7t98lo1jbpva@4ax.com>, George Neuner > >>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.
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. -- Grant Edwards grant.b.edwards Yow! I brought my BOWLING at BALL -- and some DRUGS!! gmail.com
Reply by Chris H 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 /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by D Yuniskis 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 George Neuner 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 George Neuner 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. > >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 <= 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 hamilton 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 > > >