generalized simultor infrastructure

Logged In: YES
user_id=798578
Originator: NO

Excellent idea. We shall work on this.

Logged In: NO

gpsim, the gnu pic simulator supports targets/processors to be added as plugins/libraries.

An underlying framework might expose low level facilities to easily "construct" a target, i.e.

GNUSim target = new GNUsim;
GNUsim->addRegister(....)
GNUsim->addIOPort (....)
GNUsim->addMnemnonic()

Logged In: NO

well, actually under the hood each processor could be emulated using a finite state machine, this is in fact the most common approach.
Things like "...->addRegister, ->addPort" etc would already be relatively high level, i.e. you would need to implement a state machine that is specific to processor-emulation.

FWIW, you may want to check out: http://www.freepatentsonline.com/6041176.html

Logged In: YES
user_id=798578
Originator: NO

A very good perspective indeed with respect to the state machine idea. Would you like to help us with some initial design? Also we have put a few of these ideas on our Google summer of Code 2008 ideas page here http://gnusim8085.sourceforge.net/gsoc2k8_ideas.html
Please do visit. We will move over to a wiki based page to have these interesting ideas and discussions going.

Logged In: NO

Using an implementation that is based on a FSM, a processor-specific abstract configuration could actually even be implemented in an XML-configurable fashion, so that new processors could be implemented by using a XML configurable design that would be interpreted by a pretty simple, configurable state machine, for example:

<?xml version="1.0"?>
<GNUsim8085 version="2.0" type="processor-config" name="8086" description="my fancy 8085 implementation">
  <Hardware>
    <!-- GENERIC registers -->
    <register name="AX" type="generic" size-in-bits="16" alias="AX: Work Register"/>
      <subregister name="AH" parent-register="AX" size-in-bits="8" parent-start="" parent-end="" alias=""/>
      <subregister name="AL" parent-register="AX" size-in-bits="8" parent-start="" parent-end="" alias=""/>
      ...
    <register name="BX" type="generic" size-in-bits="16" alias="BX: Base Pointer"/>
    <register name="CX" type="generic" size-in-bits="16" alias="CX: Counter"/>
    <register name="DX type="generic" size-in-bits="16" alias="DX Data Pointer"/>

    <!-- OFFSET registers -->
    <register name="BP" type="offset" size-in-bits="16" alias="BP: Base Pointer"/>
    <register name="SI" type="offset" size-in-bits="16" alias="SI: String Index"/>
    <register name="DI" type="offset" size-in-bits="16" alias="DI: Destination Index"/>
    <register name="SP" type="offset" size-in-bits="16" alias="SP: Stack Pointer"/>

    <!-- SEGMENT registers -->
    <register name="CS" type="segment" size-in-bits="16" alias="CS: Code Segment"/>
    <register name="DS" type="segment" size-in-bits="16" alias="DS: Data Segment"/>
    <register name="ES" type="segment" size-in-bits="16" alias="ES: Extra Segment"/>
    <register name="SS" type="segment" size-in-bits="16" alias="CS: Stack Segment"/>

    <!-- flags are by default boolean, i.e. size is one bit -->
    <flag name="CF" alias="Carry Flag"/>
    <flag name="PF" alias="Parity Fla"g/>
    <flag name="AF" alias="Auxiliary Flag"/>
    <flag name="ZF" alias="Zero Flag"/>
    <flag name="SF" alias="Sign Flag"/>
    <flag name="TF" alias="Trap Flag"/>
    <flag name="IF" alias="Interrupt Flag"/>
    <flag name="DF" alias="Direction Flag"/>
    <flag name="OF" alias="Overflow Flag"/>

 </Hardware>

  <Mnemonics>
  <!-- TODO: describe mnemonics: textual/opcode, params, parameter encoding -->
  </Mnemonics>
</GNUsim8085>

Something like this could also be used to describe additional hardware properties (i.e. ports, and mnemonic effects)

Logged In: NO

So, we just need to check out some possible targets that we might want to see supported one day in gnusim, this would allow us to determine the low level requirements necessary to emulate a target, find the greatest common denominator between targets such as 8051, 8086 etc

And then come up with a syntax to formally describe each target completely, so that it can be dynamically created at runtime using the aforementioned high level building blocks, which would then be only customized.

A state machine would then merely interpret those features that are common among all processors/microcontrollers, i.e.:
  - registers
  - flags
  - ports
  - memory
  - interrupts

For emulation purposes we would also be interested in explicitly referencing side-effects for each instruction (i.e. changed flags and latencies involved)

Logged In: NO

mnemonics would be described by:
  - textual name (i.e. MVI, MOV, CMP)
  - opcode representation for mnemonic
  - number of parameters [optional ones?]
  - type/size of parameters
  - parameter encoding
  - description (for use in UI)

In most lecture about assembly programming, there's a convention about describing mnemonic parameters using the following syntax:
  - imm -> immediate value
  - reg -> value from register
  - mem -> value from memory location

So, these could be used to formally describe the types of mnemonic parameters

Logged In: NO

regarding GPSim, there's another thing to take into consideration: for quite a while, those folks have been trying to add support for emulating multiple targets/CPUs simultaneously, however their architecture turned out not to be flexible enough to allow for this to happen. While I am certainly not proposing to implement anything like that within the forseeable future, it would definitively be a good idea to keep such a facility in mind, so that the design and architecture could be generic enough to eventually help implementing something like that.

Also, regarding the XML format: instruction effects would need to be fully described as well, side-effects may depend on instruction arguments and may affect various/arbitrary other processor components (registers, flags, ports, stack) this would require exposing parameter arguments via standard names, so that the following markup may easily refer to each instruction argument, for example:

<mnemonic name="MVI" description="move immediate">
  <parameters number="1">
   <param type="immediate" size="8">
     <effect type="ASSIGN_BYTE:imm->reg" val="$param1" target="reg:A"/>
   </param>

  </parameters>
</mnemonic>

Logged In: NO

regarding al/ah=>AX:

while the notion of a "subregister" may be sufficient for the 8086 (and in fact most similar processors), there are cases where a more generic approach might be better: some processors implement "SFR/SPR": special function/purpose registers, some of which often only mirror/map portions of another register, thus maybe "subregister" could be better implemented as an "alias" for a configurable bit range of another register?

Logged In: NO

Also, please note that processor status flags are often also simply one register, where individual bits are addressed by aliasing them as "flags".

Furthermore, mnemonics would probably also require support for implicit arguments

Logged In: NO

A possible XML-based implementation would probably also benefit from supporting some sort of "include" directive, so that we could maintain a library with common components that could simply be included in related XML files.

Concerning the mnemonics specs, instruction timing could also be specified using "clock cycles", so that we could specify timing properties for individual instructions by using the number of clock cycles required to execute an instruction.

In this sense, we might also want to have an additional attribute that specifies the default clock rate, and also whether this should be dynamically configurable for each processor.

Possible candidates to determine common requirements, may include:
 - 8080
 - 8085
 - 8086
 - 8088
 - 8051

All of these are fairly common and pretty widely used in various educational settings, thus there's
plenty of information availableon each of them. So that we can easily come up with an requirements
analysis to emulate each individual chip and instruction.

Hopefully, we could then generalize each instruction, so that we end up with maybe 10-20 "primitives"
that would be configurable via XML, such primitives would then be handled by a corresponding FSM.

Logged In: NO

We also need to take into account that there are different requirements when it comes to emulating a microprocessor vs. emulating a microcontroller, i.e. a microcontroller may require emulating additonal hardware such as memory, eeproms.

So, initially it will make sense to only concentrate on emulating microprocessors, however if the design is broad enough it should be possible to add support for implementing new hardware, so that eventually we may emulate microcontrollers, as well.

Having support for an include directive would thus seem to be consistent with such plans.

Several of the earlier comments are actually mainly about formally describing a processors ISA (Instruction Set Architecture):
http://en.wikipedia.org/wiki/Instruction_Set_Architecture

Personally, I think it would make sense to consider providing ISA specs separately, however having an include-directive would also address this issue, because the ISA description could reside in a separate file, while still being referenced/included in the actual file.

Logged In: NO

wow, having something like that would be really cool to enable folks to develop their own proof of concept microprocessors!
A tool supporting such facilities, could soon become VERY useful for CS/SE courses!!

Logged In: NO

regarding inclusion of other XML files, I think it would make sense to logically split these files up into:
  - processor description
  - mnemonics description (preferably honoring #1875401)
  - possibly: separate side-effects file?

Logged In: NO

there's a related RFE item on the gpsim tracker: http://sourceforge.net/tracker/index.php?func=detail&aid=1669210&group_id=2341&atid=352341 it discusses a potential approach to use scripting or a VHDL-based markup dialect to describe uC architectures and ISAs

having such an infrastructure in place would be pretty cool for computer science courses, because students could probably also use the same infrastructure to implement their own experimental processors on top of GNUsim8085.

I think, instead of redesigning GNUSim8085, it would possibly be better to integrate a scripting language such as lua, so that certain functionality can increasingly become customizable by editing scripts.

Implementing support for other processors, but also implementing support for emulating peripherals, is probably better done by a scripting language instead of hardcoding anything.

The only thing that's important though would be a lightweight and fast cross platform scripting language.

You may want to check out "nasal" (http://www.plausible.org/nasal) which is a threadsafe functional programming language written in ANSI C (GPL), Nasal can easily provide an iteration rate of several dozens khz on modern machines..

It's syntax is similar to JavaScript, but it's much easier to embed and very small, too.

Another point in support of checking out nasal is the fact that it has already gtk bindings.
So much of the current UI could probably easily ported at some point once the need arises.

Here are screenshot of two applications that were largely written in nasal using these gtk bindings:
http://www.bitminds.net/kymatica/index.php/Software/AlgoScore#screenshots
http://www.bitminds.net/kymatica/index.php/Software/KyCE

Hope this helps

This may be interesting:
http://sourceware.org/cgen/

FWIW, the following project shows up as related to GNUSim8085: http://sourceforge.net/projects/ess-sim/ :

"A cross-platform simulator for embedded systems, with a plug-in architecture for adding microcontrollers and other devices. Written in C for maximum compatibilty and speed. Currently has support for AVR AT90S8515 and ATmega128."