Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > 8085 simulator in C

Reply
Thread Tools

8085 simulator in C

 
 
Walter Roberson
Guest
Posts: n/a
 
      06-05-2007
In article <(E-Mail Removed)>,
Kenneth Brody <(E-Mail Removed)> wrote:
>Ben Pfaff wrote:


>> This sounds like a fun instruction set on which to practice
>> writing a (static or dynamic) binary translator. (Of course,
>> there's no way to actually run the translated code without
>> invoking undefined behavior, from a comp.lang.c point of view.)


>How so? You have a struct holding the emulator's CPU registers, and a
>64K unsigned char array (or two 32K arrays, since I seem to recall the
>standard not requiring support for 64K arrays) representing the memory.


Ben is talking about binary *translator* -- i.e., that the 8085 binary
code be examined and converted to code native to the hosting system
and run directly as native code instead of by emulating each 8085
instruction. And he is correct that you can't actually run the
translated code without undefined behaviour, as C does not offer
any mechanism to compute native code and set that code into execution.

For example, C does *not* offer

unsigned char object_code[SomeSizeOrOther];
object_code[SomeLocationOrOther] = SomeNativeOpcodeOrOther;
((void(*)()) object_code)(); /* undefined behaviour! */

There is no C facility to convert an object pointer into a function
pointer.
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes
 
Reply With Quote
 
 
 
 
Scott Fluhrer
Guest
Posts: n/a
 
      06-05-2007

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> On Jun 5, 11:28 am, Jean-Marc Bourguet <(E-Mail Removed)> wrote:
>> (E-Mail Removed) writes:
>> > You can still get the Z80 at DigiKey. Same instruction set, even
>> > easier to connect up (the address and data bus are not multiplexed
>> > like on the 8085).

>>
>> I think you are confusing 8080 and 8085.
>>
>> --
>> Jean-Marc, who has programmed both but could be the one doing the
>> confusion

>
> Nope, the 8080 used an external clock generator (8224) and system
> controller (822 that were built into the 8085. There are a couple of
> undefined opcodes in the 8080/8085 that the Z80 defined to extend the
> architecture of the 8080/8085. It doubled the number of registers,
> demuxed the IO, and added a few new registers. However, as long as you
> don't use those undefined opcodes, it is 100% software compatible
> (only the timing is different).

Oops, only 99.99% software compatible -- if you did an 8 bit add or
subtract, the 8080/8085 would save the parity of the result into the 'parity
flag', while the Z80 would save whether the operation overflowed into the
parity flag. That generally came up only if you were deliberately writing
code that would work differently on the different processors, but it is a
difference.

--
poncho


 
Reply With Quote
 
 
 
 
Kenneth Brody
Guest
Posts: n/a
 
      06-06-2007
Walter Roberson wrote:
>
> In article <(E-Mail Removed)>,
> Kenneth Brody <(E-Mail Removed)> wrote:
> >Ben Pfaff wrote:

>
> >> This sounds like a fun instruction set on which to practice
> >> writing a (static or dynamic) binary translator. (Of course,
> >> there's no way to actually run the translated code without
> >> invoking undefined behavior, from a comp.lang.c point of view.)

>
> >How so? You have a struct holding the emulator's CPU registers, and a
> >64K unsigned char array (or two 32K arrays, since I seem to recall the
> >standard not requiring support for 64K arrays) representing the memory.

>
> Ben is talking about binary *translator* -- i.e., that the 8085 binary
> code be examined and converted to code native to the hosting system
> and run directly as native code instead of by emulating each 8085
> instruction.


Ah. I was thinking "emulator" rather than "translator". Of
course, something that generates (portable) C source code which
is to be compiled elsewhere could qualify as a "translator".

> And he is correct that you can't actually run the translated code
> without undefined behaviour, as C does not offer any mechanism to
> compute native code and set that code into execution.
>
> For example, C does *not* offer
>
> unsigned char object_code[SomeSizeOrOther];
> object_code[SomeLocationOrOther] = SomeNativeOpcodeOrOther;
> ((void(*)()) object_code)(); /* undefined behaviour! */
>
> There is no C facility to convert an object pointer into a function
> pointer.


Is this actually UB, or is it "implementation defined"?

Also, isn't a compiler allowed to define the behavior which is UB
according to the standard? In other words, a compiler _could_
explicitly allow such a construct, with the caveat (of course)
that the pointer must point to valid machine code, to allow
things similar to Java's JIT[1] compiler.


[1] JIT == "Just In Time". As I understand it, the Java bytecode is
compiled into native machine code as the program runs.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <(E-Mail Removed)>


 
Reply With Quote
 
mstorkamp@yahoo.com
Guest
Posts: n/a
 
      06-06-2007
On Jun 5, 5:01 pm, CBFalconer <(E-Mail Removed)> wrote:
>
> He is better off simulating the 8080 instruction set, which can
> then be expanded into the Z80 set, which in turn can be expanded
> into the 64180 set. The 8085 is a dead end.
>


I think you are confusing 8085 and 8086/8088.

 
Reply With Quote
 
Scott Fluhrer
Guest
Posts: n/a
 
      06-06-2007

"Kenneth Brody" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Walter Roberson wrote:
>>
>> In article <(E-Mail Removed)>,
>> Kenneth Brody <(E-Mail Removed)> wrote:
>> >Ben Pfaff wrote:

>>
>> >> This sounds like a fun instruction set on which to practice
>> >> writing a (static or dynamic) binary translator. (Of course,
>> >> there's no way to actually run the translated code without
>> >> invoking undefined behavior, from a comp.lang.c point of view.)

>>
>> >How so? You have a struct holding the emulator's CPU registers, and a
>> >64K unsigned char array (or two 32K arrays, since I seem to recall the
>> >standard not requiring support for 64K arrays) representing the memory.

>>
>> Ben is talking about binary *translator* -- i.e., that the 8085 binary
>> code be examined and converted to code native to the hosting system
>> and run directly as native code instead of by emulating each 8085
>> instruction.

>
> Ah. I was thinking "emulator" rather than "translator". Of
> course, something that generates (portable) C source code which
> is to be compiled elsewhere could qualify as a "translator".
>
>> And he is correct that you can't actually run the translated code
>> without undefined behaviour, as C does not offer any mechanism to
>> compute native code and set that code into execution.
>>
>> For example, C does *not* offer
>>
>> unsigned char object_code[SomeSizeOrOther];
>> object_code[SomeLocationOrOther] = SomeNativeOpcodeOrOther;
>> ((void(*)()) object_code)(); /* undefined behaviour! */
>>
>> There is no C facility to convert an object pointer into a function
>> pointer.

>
> Is this actually UB, or is it "implementation defined"?


Undefined Behavior. "Implementation defined" means that the implementation
is required to document it, and the Standard places no such requirement.

>
> Also, isn't a compiler allowed to define the behavior which is UB
> according to the standard?


Of course. Undefined Behavior means the Standard places no requirements,
and so the implementation is free to do whatever it wants. If it wants to
define the behavior in a particular way, and additionally to document what
this behavior is, that's just fine.

> In other words, a compiler _could_
> explicitly allow such a construct, with the caveat (of course)
> that the pointer must point to valid machine code, to allow
> things similar to Java's JIT[1] compiler.
>
>
> [1] JIT == "Just In Time". As I understand it, the Java bytecode is
> compiled into native machine code as the program runs.
>
> --
> +-------------------------+--------------------+-----------------------+
> | Kenneth J. Brody | www.hvcomputer.com | #include |
> | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
> +-------------------------+--------------------+-----------------------+
> Don't e-mail me at: <(E-Mail Removed)>
>
>



 
Reply With Quote
 
Bill Leary
Guest
Posts: n/a
 
      06-07-2007
<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ps.com...
> You can still get the Z80 at DigiKey. Same instruction set, even
> easier to connect up (the address and data bus are not multiplexed
> like on the 8085).


Not the same instruction set. The common denominator is the 8080. The Z80
adds a lot of new instructions. The 8085 added a few new instructions.
Some of those new ones for the 8085 use the same op-codes as new ones for
the Z80, but do entirely different things. There were also a few flags
which responded differently on the 8085 than they did on the 8080 or Z80.
When we wanted a single executable to run on two or three of these devices,
we used to write "detector code" which nudged at these flags and
instructions to figure out which machine the code was running on.

If one want's to use other processors "based" at 8080 there's also the
64180, the Z180 (Z80's with MMUs and a few other new features) and the
processor in the original Game Boy, which included some, but not all, of the
Z80 additional instructions and, as I recall, a few of it's own, and I seem
to remember an Intel 8080 or 8085 based CPU intended specifically for the
embedded market which had a few other additional instructions specifically
intended to cut down on external I/O hardware.

- Bill

 
Reply With Quote
 
Bart van Ingen Schenau
Guest
Posts: n/a
 
      06-07-2007
Kenneth Brody wrote:

> Walter Roberson wrote:
>>
>> For example, C does *not* offer
>>
>> unsigned char object_code[SomeSizeOrOther];
>> object_code[SomeLocationOrOther] = SomeNativeOpcodeOrOther;
>> ((void(*)()) object_code)(); /* undefined behaviour! */
>>
>> There is no C facility to convert an object pointer into a function
>> pointer.

>
> Is this actually UB, or is it "implementation defined"?


The C standard does not define the behaviour, therefor it is UB.
This does not preclude other standards (like POSIX), or the compiler
writers themselves to specify what behaviour will happen.

UB merely means that the C standard does not restrict the behaviour of
the construct. Therefor, you should not use such constructs in code
that must be portable to all possible C implementations, as you can't
know what the behaviour will be.

In practice do compilers also implement other standards, like POSIX, or
have people come to rely on certain behaviours which all may indicate a
certain behaviour for constructs that are UB under the C standard
alone.

Due to the topicality of this group, we only look to the C standard to
see what behaviour we will get, so we will mark thing as undesirable
(due to UB) which are fairly common in other environments.

>
> Also, isn't a compiler allowed to define the behavior which is UB
> according to the standard? In other words, a compiler _could_
> explicitly allow such a construct, with the caveat (of course)
> that the pointer must point to valid machine code, to allow
> things similar to Java's JIT[1] compiler.


Yes, and other standards may even require that the compiler does so.

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
 
Reply With Quote
 
CINVESTAV CINVESTAV is offline
Junior Member
Join Date: Jan 2012
Posts: 1
 
      01-09-2012
i'm interested in your idea. i would like to know if could deloveped the program in c. i have some ideas and i wonder if you could help me
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
processor 8085 processor 8085 Microsoft Certification 8 01-27-2008 02:58 PM
vhdl code for 8085 dipu bhaskar VHDL 2 02-11-2004 08:54 PM
Bit-Level C Simulator Kingsley Oteng VHDL 4 01-21-2004 12:25 PM
VHDL Simulator Options Mike Kopp VHDL 3 09-23-2003 03:44 PM
Free VHDL Simulator Basuki Endah Priyanto VHDL 1 08-15-2003 11:14 AM



Advertisments