Searching \ for '[PIC]: fast emulator' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'fast emulator'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: fast emulator'
2003\02\07@091256 by

flavicon
picon face
Hi everyone,

I have been experimenting with writing a PIC emulator, and was hoping for
some advice. I started doing this as a way of demonstrating the power of
dynamic compilation. The result is a (currently partially-complete) PIC
emulator which I have tested at sustained speeds of around 80 MIPS on my
300MHz computer (and I mean with genuine code downloaded from the internet,
not code contrived to be gentle to the emulator).

This is far faster than I am aware of any currently-available emulators
managing. Of course, this speed is reduced a little sometimes (for parts of
the program which deal with ports and with complex control registers such as
the OPTION register, and for programs which use lots of timers of very short
[< 20 cycles] duration), but the joy of dynamic compilation is that this
reduction can be minimized. In addition, features such as logging,
conditional breakpoints, watchpoints and the like can be implemented with
very little overhead (and none at all in areas of code that are not
affected) - and time-delay loops can be identified at compile-time and
optimized to be VERY fast indeed.

What I am hoping for advice on is whether it is worth pursuing this project.
It has served its purpose well as a demonstration of dynamic compilation. I
am now trying to decide whether I should continue and take the time to
produce a program that others could use for their development. I am
confident that it would perform far better than existing emulators (unless
there's one I'm not aware of), but the question is whether that is actually
*necessary*.

Do you find that existing emulators are too slow for your needs (or are not
able to provide the features that you want without compromising emulation
speed), or are they actually sufficient? I have some very good ideas for
features that would be useful in a PC-based emulator, but I know that there
are a number of existing emulators available. I don't feel it is worth the
effort of writing another one unless it has a compelling advantage over the
existing ones.

There is one further caveat to my claims. The prototype that I have written
runs on a Macintosh computer, which I know is not the most popular of
platforms :). Unfortunately dynamic compilation is about as
platform-specific as you can get, so porting it to Windows or Linux would
not be trivial. Unless someone else was interested in transferring my ideas
over to such a platform (maybe based on the platform-independent core of my
code), this would probably reduce the popularity of my emulator.

Incidentally, one particular feature which someone suggested to me was that
a fast software emulator could easily be linked up to a circuit board as a
way of providing in-circuit emulation with all the advantages of running it
from a PC and without the expense of dedicated ICE hardware. I am very
interested by this possibility (has it been done before?) although I
recognise that it would be limited by latencies in the data transfer between
computer and circuit, preventing it from being useful in some applications
where precise I/O timing was critical.

I would be very grateful for advice (on or off list) on whether people think
this is worth spending time on - even if it's just a "I would/wouldn't use
it".

Thanks very much in advance
Jonny

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\07@100211 by Scott Dattalo

face
flavicon
face
On Fri, 7 Feb 2003, Jonny Taylor wrote:

> Hi everyone,
>
> I have been experimenting with writing a PIC emulator, and was hoping for
> some advice. I started doing this as a way of demonstrating the power of
> dynamic compilation. The result is a (currently partially-complete) PIC
> emulator which I have tested at sustained speeds of around 80 MIPS on my
> 300MHz computer (and I mean with genuine code downloaded from the internet,
> not code contrived to be gentle to the emulator).

You oughta check out gpsim.

If you optimized gpsim to just execute code (and not worry about I/O
ports, peripherals, interrupts, etc.) then 80 MIPS would be easily
achievable. As it stands, on a 300MHz computer gpsim can sustain ~20
Mips.

http://www.dattalo.com/gpsim.html

In my opinion, an 80MIP simulator without breakpoints, peripherals, I/O's,
user interface, etc. is only useful for a small subset of problems. One
subset is automatic code generation for algorithm development. For
example, you can define an algorithms' inputs and outputs and exhaustively
search all combinations of instructions for the most efficient solution.
Unfortunately, even with a *very* fast simulator, the execution time is
prohibitively long except for simple algorithms. In the vertical adder
code generator, I verified Dimitry's six-instruction solution and found 5
other solutions:

http://www.dattalo.com/technical/software/pic/va_optimizer2.c

This is a brute force, special purpose simulator that exhaustively searchs
all 6-instruction combinations for set of 32 "instructions". (I quote
"instructions" because I consider "movf REG,F" to be different than "movf
REG,W"). The number of 6-instruction programs that exist for this subset
of possible instructions is:

 Programs = (Instructions) ^ (Program Length)
          = 32 ^ 6
          = 1.07 billion programs

If you execute everyone of these programs, that's:

 Executed instructions = Programs * Program Length
                       = (32^6) * 6
                       = 6.4 billion
On my 400MHz Linux box:

$ gcc -O2 -o v va_optimizer2.c
$ time ./v

real    6m13.099s
user    6m8.550s
sys     0m0.860s

6.4 billion instructions / (6*60 + 13) ~ 17 Mips

Geez, that's slow! :)

But, this specialized simulator does more than simulation. It has to set
up the initial conditions, write the program, execute the program, and
examine the results... I bet your simulator could be configured for this
algorithm and run 2 or 3 times faster!

Scott

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\07@103105 by Olin Lathrop

face picon face
> Do you find that existing emulators are too slow for your needs (or are
not
> able to provide the features that you want without compromising
emulation
> speed), or are they actually sufficient?

The existing MPLAB simulator is very slow.  It may be based on 16 bit DOS
code, but it's still hard to imagine where the cycles go.

I personally don't use the simulator much because we have two ICE-2000
here.  I have gotten good results from it the few times I've used it for
simple things like 12C508 that isn't worth getting an emulator device
adaptor for, or when the emulator components or target circuit weren't
available yet.  While it is very slow, that has only been an annoyance
once during a few hours worth of work.  Most of the time I'm checking out
logic that executes in a few cycles or a few thousand cycles, and the
simulator speed just isn't an issue.

The top of my wishlist for the simulator is to give me external hooks so
that I can supply my own compiled host code to be triggered on particular
events.  For example, a couple of times I wished I could capture a write
to TXREG or intercept a read from RCREG, which would then allow me to get
data from a file, drive the PC serial port, or whatever.

Another problem with a third party simulator is that it wouldn't be
integrated into MPLAB.  The only reason I've ever used the simulator was
to debug and verify code.  A simulator that can't single step thru my
source code is useless.  If it's just a bare simulator that can't tell me
what's going on inside, I might as well load the code onto a real chip and
run it.

Sorry this probably isn't what you wanted to hear, but you asked.  Most
hobbyists don't seem to have an ICE, so they probably use the simulator
more heavily.  They probably care about it a lot more than I do.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\07@122345 by William Chops Westfield

face picon face
   > Do you find that existing emulators are too slow for your needs (or
   > are not able to provide the features that you want without
   > compromising emulation speed), or are they actually sufficient?

   The existing MPLAB simulator is very slow.  It may be based on 16 bit
   DOS code, but it's still hard to imagine where the cycles go.

Yes.  I just started trying to actually use MPLAB's simulator, and it is
very annoying indeed, speed wise.  Especially if you start to use features
like breakpoints/etc.

On the other hand, I don't see any reason for a simulator to run faster
than 'real time.'  If you're at 80 MIPS (320MHz?!), then you are surely
fast enough, and commands that REDUCE speed to real time might be useful.
Given speed, it would be time to start working on other features, such as
support for other processors, operating systems, IDE and/or source
integration, extensibility, and so on.  Boring stuff, if your main interest
was using incremental compilation to achieve blinding speed. :-(

BillW

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\07@141038 by Stef

flavicon
face
hi Jonny,

I'm not a software guy, so I don't know what dynamic compilation stands
for (but I can imagine something).
I'm still very interested to see your ideas/algoritme/sources, because
I'm building a simulator too.
I guess, my approach is totally different from yours, my first goal is
to make the simulator so easy, that it can be used by children from the
age of 12 or so.  But on the other hand it must be so powerfull that it
can be used by professionals. Other features: freeware and any device
can be dynamically implemented through an external DLL. Speed is not my
first priority, but It would be nice if it would run maximum 10 times as
slow as real time for 1 PIC @20MHz, with some additional hardware
components. A first quiet buggy version can be found at my site
 oase.uci.kun.nl/~mientki/PIC/JALss/JALss.htm
At least you can get an idea of what I've in mind with a simulator.
I'll hope to see something of your work.

cheers,
Stef Mientki

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\07@143841 by

flavicon
picon face
Scott,

Sorry if I have misunderstood what you meant in your comments, but I wonder
if I didn't explain the performance of the program clearly. I can see that
gpsim is a quality emulator, but I do genuinely believe that I can outdo it
by several times. I am quite willing to be discouraged if people feel that
gpsim (and others) are sufficient for their needs, but think I would have
something to offer if there was demand for it.

{Quote hidden}

Granted, the 80MIPS I quoted *was* just for code execution. However, I am
confident that this speed will *not* be slashed with the addition of these
extra items. Active peripherals, running timers, enabled interrupts can all
be going on with very little (I estimate 10-20%) overhead. It is only for a
few instructions around when an interrupt fires (*) that performance would
drop significantly. Naturally, a program could be written that I probably
couldn't emulate faster than gpsim. In one that had every 5 instructions
(say) something like a port read, indirect addressing, storing to a timer
register or having an interrupt fire, there would be so much going on that
it would be very difficult to speed up. However I suspect (though I may be
wrong) that the sort of programs that would benefit from very fast emulation
would contain quite a bit of "calculations" in addition to interactions with
peripherals, etc.

(*) that assumes, of course, that all interrupts can be predicted in
advance. The only reason I can think of where this would not be the case is
if the program was linked up to a real circuit, when external interrupts
couldn't be predicted. But in that case you're probably going to be after
real-time emulation anyway, rather than faster-than-realtime.

The same goes for breakpoints (zero overhead), conditional breakpoints (only
the overhead of evaluating the condition [in compiled code] when the
breakpoint is hit), watchpoints (only evaluating the condition when the
register is written, and checking where an indirect address was destined
for). For logging the overhead in logging to an encoded buffer would vary
from about 20% overhead (just logging which lines were executed) to a
worst-case of about 100% overhead - i.e. half speed - if every changed
register and all peripheral behaviour is logged.

All these are of course just claims at the moment, but they are based on a
carefully thought out low-level design (it's just that I haven't actually
implemented all of it yet), rather than just idle speculation.

> In my opinion, an 80MIP simulator without breakpoints, peripherals, I/O's,
> user interface, etc. is only useful for a small subset of problems. One
> subset is automatic code generation for algorithm development.

> But, this specialized simulator does more than simulation. It has to set
> up the initial conditions, write the program, execute the program, and
> examine the results... I bet your simulator could be configured for this
> algorithm and run 2 or 3 times faster!
Actually, I think that's one thing that it probably wouldn't be good at. I
suspect the overhead in compiling the code and setting it all up (for each
individial test case, or even for a batch at a time) would be too great.

If you still stand by what you wrote, then please accept my apologies :) and
I will take your advice. I have a feeling I may just not have been clear
enough in my original message, though.

> Scott
Jonny

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\07@145534 by Scott Dattalo

face
flavicon
face
On Fri, 7 Feb 2003, Jonny Taylor wrote:

> Scott,
>
> Sorry if I have misunderstood what you meant in your comments, but I wonder
> if I didn't explain the performance of the program clearly. I can see that
> gpsim is a quality emulator, but I do genuinely believe that I can outdo it
> by several times. I am quite willing to be discouraged if people feel that
> gpsim (and others) are sufficient for their needs, but think I would have
> something to offer if there was demand for it.

If you can outdo gpsim by a factor of 4 I'd be impressed! I have no doubt
that gpsim *could* be made faster - but when I was at your stage of the
development, I profile the code, looked at the assembly, and in general
optimized any way I could.

{Quote hidden}

Actually gpsim has these features as well. The simulation loop in gpsim
looks something like this:
 while(!break point)
   programMemory[ProgramCounter.value]->execute();

In other words, pointers to functions are used to simluate the
instructions. Breakpoints simply swap out the ptf's with break point
functions. Similarly, ram is accessed with ptf's too. Thus write break
points are implemented with a similar mechanism. Simple, and efficient.

The slow down for gpsim mainly occurs because of banking. The register
and program memory banking are dynamic aspects of a pic that can't be
statically coded like instruction simulation.

Another slow down in gpsim is that callback functions are implemented.
These are special functions that are keyed on the cycle counter. They're
mainly used to support peripherals like TMR0, TMR1, TM2, A/D, uart, etc.
But they're also used to generate stimuli like square waves, analog
signals, etc. Oh, and one more usage is to service the gui.

{Quote hidden}

No need to apoligize! And yes, I stand by what I wrote. :) If you can
improve the performance of gpsim and wish to submit a patch, then great.
If you can outdo gpsim in anyway, then that's great too.

Regards,
Scott

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\07@145748 by Alex Holden

flavicon
face
On Fri, 2003-02-07 at 15:00, Scott Dattalo wrote:
> In my opinion, an 80MIP simulator without breakpoints, peripherals, I/O's,
> user interface, etc. is only useful for a small subset of problems. One
> subset is automatic code generation for algorithm development. For
> example, you can define an algorithms' inputs and outputs and exhaustively
> search all combinations of instructions for the most efficient solution.
> Unfortunately, even with a *very* fast simulator, the execution time is
> prohibitively long except for simple algorithms. In the vertical adder
> code generator, I verified Dimitry's six-instruction solution and found 5
> other solutions:

I think there could be the potential for a SetiAtHome style distributed
computing effort here. Pick some common algorithm that's normally
dismissed as being impractical to perform a brute force optimisation on
because of its complexity, and distribute chunks of the problem space
(groups of instruction sequences) over the net to daemons which sit in
the background on peoples normally idle computers churning through
billions of possible instruction sequences in search of the shortest
sequences (or the first match of a particular length) that produces the
desired results. It would be even better if the instruction sequence
cracking engine was generic enough to try to solve any arbitrary problem
that it was given, so the daemons didn't need to be replaced once the
first problem was solved and a new one proposed.

> 6.4 billion instructions / (6*60 + 13) ~ 17 Mips
> Geez, that's slow! :)

51 Mips here on my Athlon 1600 XP compiled with GCC 3.2.1 and
-mcpu=athlon-xp -O3 -fomit-frame-pointer :)

--
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\07@160825 by Herbert Graf

flavicon
face
> On the other hand, I don't see any reason for a simulator to run faster
> than 'real time.'

       I disagree. Certain controllers structures can appear perfectly stable
after an hour or two of run time, only to blow up after an hour. Having a
SIM that does faster then real time can be VERY handy sometimes. TTYL

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\07@161240 by Peter L. Peres

picon face
On Fri, 7 Feb 2003, William Chops Westfield wrote:

*>On the other hand, I don't see any reason for a simulator to run faster
*>than 'real time.'  If you're at 80 MIPS (320MHz?!), then you are surely
*>fast enough, and commands that REDUCE speed to real time might be useful.

You are saying that because you never had to debug handmade delay code
that must delay by say 2756113 T cycles exactly. Imho there is no such
thing as a too fast simulator. And you can't always start the simulator
and read a book while it runs like I had to do with MPLAB.

Peter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\07@174840 by Andy Kunz

flavicon
face
>Another problem with a third party simulator is that it wouldn't be
>integrated into MPLAB.  The only reason I've ever used the simulator was

That's a blessing, Olin.

Andy

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\08@023609 by Sergio Masci

picon face
----- Original Message -----
From: Jonny Taylor <jonathan.taylorspamKILLspamUNIVERSITY-COLLEGE.OXFORD.AC.UK>> To: <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU>
Sent: Friday, February 07, 2003 2:02 PM
Subject: [PIC]: fast emulator


> Hi everyone,
>
> I have been experimenting with writing a PIC emulator, and was hoping for
> some advice. I started doing this as a way of demonstrating the power of
> dynamic compilation. The result is a (currently partially-complete) PIC
> emulator which I have tested at sustained speeds of around 80 MIPS on my
> 300MHz computer (and I mean with genuine code downloaded from the
internet,
> not code contrived to be gentle to the emulator).
>
> This is far faster than I am aware of any currently-available emulators
> managing. Of course, this speed is reduced a little sometimes (for parts
of
> the program which deal with ports and with complex control registers such
as
> the OPTION register, and for programs which use lots of timers of very
short
> [< 20 cycles] duration), but the joy of dynamic compilation is that this
> reduction can be minimized. In addition, features such as logging,
> conditional breakpoints, watchpoints and the like can be implemented with
> very little overhead (and none at all in areas of code that are not
> affected) - and time-delay loops can be identified at compile-time and
> optimized to be VERY fast indeed.
>
> What I am hoping for advice on is whether it is worth pursuing this
project.
> It has served its purpose well as a demonstration of dynamic compilation.
I
> am now trying to decide whether I should continue and take the time to
> produce a program that others could use for their development. I am
> confident that it would perform far better than existing emulators (unless
> there's one I'm not aware of), but the question is whether that is
actually
> *necessary*.
>
> Do you find that existing emulators are too slow for your needs (or are
not
> able to provide the features that you want without compromising emulation
> speed), or are they actually sufficient? I have some very good ideas for
> features that would be useful in a PC-based emulator, but I know that
there
> are a number of existing emulators available. I don't feel it is worth the
> effort of writing another one unless it has a compelling advantage over
the
> existing ones.
>
> There is one further caveat to my claims. The prototype that I have
written
> runs on a Macintosh computer, which I know is not the most popular of
> platforms :). Unfortunately dynamic compilation is about as
> platform-specific as you can get, so porting it to Windows or Linux would
> not be trivial. Unless someone else was interested in transferring my
ideas
> over to such a platform (maybe based on the platform-independent core of
my
> code), this would probably reduce the popularity of my emulator.

I assume by this that what you actually mean is that each PIC instruction is
converted to a sequence of host instructions. That you build a native host
executable that does not execute a given function per instruction, no call
or returns.

The thing is, most simulators do hardware specific simulation at every CPU
cycle. They interleave instruction and hardware simulation. You also need to
trace instructions as they are processed. You need to provide the user with
a mechanism where they can run to a break point then check to see what
events occured that lead to that point. A trace buffer of some kind is
invaluable. With this you would need to show what changes occured,
instruction by instruction, so that the user can work his/her way back.
Again this does not go well with non-stop no-boundry execution.

>
> Incidentally, one particular feature which someone suggested to me was
that
> a fast software emulator could easily be linked up to a circuit board as a
> way of providing in-circuit emulation with all the advantages of running
it
> from a PC and without the expense of dedicated ICE hardware. I am very
> interested by this possibility (has it been done before?) although I
> recognise that it would be limited by latencies in the data transfer
between
> computer and circuit, preventing it from being useful in some applications
> where precise I/O timing was critical.

not just that, but your simulated processor cycles will have different times
depending on which instruction is being simulated. If you are going to
simulate a processor you need to be able to accurately predict timing. It
cannot run at 100 MIPS in loop A and 90 MIPS in loop B. That would really
cause you problems.

>
> I would be very grateful for advice (on or off list) on whether people
think
> this is worth spending time on - even if it's just a "I would/wouldn't use
> it".
>
> Thanks very much in advance
> Jonny

I don't want to put you off. I just think that these are things you should
consider carefully. Look at specific PIC and consider how you would simulate
ALL the hardware (e.g. A/D, UART, I2C, EEPROM read/write, PORT B interrupts,
watchdog). As personal projects go I certainly think it is worth while.

Regards
Sergio Masci
http://www.xcprod.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\08@023624 by Sergio Masci

picon face
----- Original Message -----
From: Olin Lathrop <EraseMEolin_piclistspam_OUTspamTakeThisOuTEMBEDINC.COM>
To: <PICLISTspamspam_OUTMITVMA.MIT.EDU>
Sent: Friday, February 07, 2003 3:30 PM
Subject: Re: [PIC]: fast emulator


> The top of my wishlist for the simulator is to give me external hooks so
> that I can supply my own compiled host code to be triggered on particular
> events.  For example, a couple of times I wished I could capture a write
> to TXREG or intercept a read from RCREG, which would then allow me to get
> data from a file, drive the PC serial port, or whatever.

XCSIM lets you do that and a lot more. A really nice feature is that you can
embed high level simulation commands directly in your assembler source and
these commands get executed by the simulator when the appropriate
instruction is reached. You could add simulation statements to your macros
to validate their use. You could add simulation statements to your library
functions to validate their inputs and results. I like to use XCSIM to
validate algorithms running on a PIC against a reference running on a PC.

http://www.pic-simulator.org

Regards
Sergio Masci

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\08@051718 by Alex Holden

flavicon
face
On Fri, 2003-02-07 at 19:56, Alex Holden wrote:
> I think there could be the potential for a SetiAtHome style distributed
> computing effort here. Pick some common algorithm that's normally

I've been thinking about this some more, and it got me wondering as to
whether anybody has played around with genetic algorithms for the
automated generation of PIC code to solve some simple task (say maze
solving or pattern recognition)?

Evolving an insect-level robot control program (I hesitate to say
"brain") over millions of generations using a distributed network of
faster than real time simulators, and then downloading the resulting
program to a real robot strikes me as a very interesting project.

--
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\09@121406 by

flavicon
picon face
> I've been thinking about this some more, and it got me wondering as to
> whether anybody has played around with genetic algorithms for the
> automated generation of PIC code to solve some simple task (say maze
> solving or pattern recognition)?
>
> Evolving an insect-level robot control program (I hesitate to say
> "brain") over millions of generations using a distributed network of
> faster than real time simulators, and then downloading the resulting
> program to a real robot strikes me as a very interesting project.
I'm afraid I can't find the website now (maybe someone else can point you
towards it), but I seem to remember seeing a description of a population of
insect-like robots powered by PICs that someone had built. Their programs
were the result of some sort of genetic algorithm, but I have a feeling it
operated at a higher level - more function-level evolution rather than
instruction-level.

Jonny

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\09@130255 by

flavicon
picon face
>> Hi everyone,
>>
>> I have been experimenting with writing a PIC emulator, and was hoping for
>> some advice. I started doing this as a way of demonstrating the power of
>> dynamic compilation. The result is a (currently partially-complete) PIC
>> emulator which I have tested at sustained speeds of around 80 MIPS on my
>> 300MHz computer (and I mean with genuine code downloaded from the
> internet,
>> not code contrived to be gentle to the emulator).
>>
> I assume by this that what you actually mean is that each PIC instruction is
> converted to a sequence of host instructions. That you build a native host
> executable that does not execute a given function per instruction, no call
> or returns.
Yes, the idea is to eliminate as much as possible of the "simulation
framework" code, just leaving the actual translated PIC instructions, the
code for maintaining the correct state of the peripheral and the logging,
breakpoint etc code.

No, I do not build a native host executable, though. I construct the native
code in a buffer in memory and then call the function that I have assembled.
It of course takes time to compile, but can be recompiled quickly enough
(since I don't perform any particularly complex optimizations) that you can
stop the program, alter something (like a breakpoint) and then run it again
with the recompiled code without a noticable delay.

> The thing is, most simulators do hardware specific simulation at every CPU
> cycle. They interleave instruction and hardware simulation. You also need to
> trace instructions as they are processed. You need to provide the user with
> a mechanism where they can run to a break point then check to see what
> events occured that lead to that point. A trace buffer of some kind is
> invaluable. With this you would need to show what changes occured,
> instruction by instruction, so that the user can work his/her way back.
> Again this does not go well with non-stop no-boundry execution.
Yes, I interleave code that does this between the instructions... but most
of it doesn't have to be between *every* instruction. For example there is
no need to record every instruction in the trace buffer - just which
branches were taken (though details of register contents may be required as
well). To give another example, it is often possible to identify places
where an instruction affects the status register, but that result is
definitely not acted upon before it's overwritten by another result. In that
case, I often don't need to bother updating it at all (as long as no
breakpoint comes up the user will never see the temporarily-incorrect status
register value).

{Quote hidden}

Yep - but you only need to synchronise on some instructions. As long as you
know you have simulated 1001 instructions since the last time port IO
occurred (or whatever) you know you have to wait until 1001/(clock speed)
secs have elapsed before doing the read (and you might even be able to do
something like dump the trace buffer to disk while you wait...).

> I don't want to put you off. I just think that these are things you should
> consider carefully. Look at specific PIC and consider how you would simulate
> ALL the hardware (e.g. A/D, UART, I2C, EEPROM read/write, PORT B interrupts,
> watchdog). As personal projects go I certainly think it is worth while.

Thanks very much for some very useful suggestions.

Jonny

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\09@133619 by Alex Holden

flavicon
face
On Sun, 2003-02-09 at 17:12, Jonny Taylor wrote:
> I'm afraid I can't find the website now (maybe someone else can point you
> towards it), but I seem to remember seeing a description of a population of
> insect-like robots powered by PICs that someone had built. Their programs
> were the result of some sort of genetic algorithm, but I have a feeling it
> operated at a higher level - more function-level evolution rather than
> instruction-level.

Very interesting. I'm going to have a go at implementing a system to
evolve some very basic programs at instruction level using a test
harness wrapped around gpsim. I'll check back in with the list if I get
it to produce anything interesting.

--
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...