Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
03/04/05 21:27
Read: times


 
#89137 - not so fast
Responding to: ???'s previous message
There is a difference, if the translation should be working at all times, or be efficient.
For example, how would you implement the register file (R0-R7)? If you implement it in RAM, this is woud be exact, but painfully slow, as each instruction involving Rx would first check RB0-1 bits in simulated PSW to determine, which bank to use, then move the register from and to RAM. Keeping simulated registers in the register area of AVR is impossible, as there are only 32 AVR registers. Keeping the current R0-R7 set in AVR registers is viable, checking for changes in RBi bits after each change of PSW and sweeping out and in the whole set - BUT this also requires extensive testing, if direct (checkable at time of translation) and indirect (worse, indirect checking) access is made to addresses matching the current register file and redirect that access from RAM to AVR registers... Not trivial at all.
On the other hand, '51 programs tend to use bank 0 throughout the whole program, using other banks only in a small, well defined area (interrupts); and they don't point indirectly into the register area. So for most users, it is enough to translate a significantly simpler hence shorter and faster code, and the user could eventually corect those few lines by hand.
Of course, properly map/translate peripherals and interrupts (note that AVRs don't have interrupt prioritisation), that's another HUGE issue.
Or, just a small nuissance, the parity flag. To do it properly, it must be recalculated after each change of accumulator, or better, before each access to PSW (e.g. consider push psw; mov r0,sp; mov a,@r0; jb acc.parity-bit-position,xx). Calculating parity on AVR is a lengthy task (been there). But the vast majority of 51 programs don't use parity at all...
Very similarly, proper simulation of AC flag and DAA would make ADDs and SUBs too complicated - and it is questionable if it is worth that. (Just a curiosity - AVRs don't have ADD register,#immediate...).

And, how would you translate PUSH SP to match the actual behaviour of '51? :-)

Jan Waclawek

PS Besides translation (= compilation), it is possible to simulate (= interpret) a processor inside other processor. An interesting project, remake of a (czecho)slovak school computer PMD85 by a single AVR with one RAM and one ROM chip, can be found at avrfreaks. It contains a complete enulation of i8080 - this may serve partially as an inspiration here, too.

List of 15 messages in thread
TopicAuthorDate
8051 Assembler Source Converter ??            01/01/70 00:00      
   If you can't find one...            01/01/70 00:00      
      Try to speak with guys from datatek            01/01/70 00:00      
   sdcc            01/01/70 00:00      
   Translator            01/01/70 00:00      
      not so fast            01/01/70 00:00      
         Shove, not push            01/01/70 00:00      
            8051 & AVR similar?            01/01/70 00:00      
               C            01/01/70 00:00      
                  Of course C !            01/01/70 00:00      
               acc - the least of a problem            01/01/70 00:00      
         Assumptions            01/01/70 00:00      
   let's try...            01/01/70 00:00      
   in the olden days, I did            01/01/70 00:00      
      I'm inclined to C            01/01/70 00:00      

Back to Subject List