I'm starting to worry about the performance of MoCog.
A lot of 6809 op/addressing mode combinations took 4, 5, or 6 cycles. Most indexed addressing mode ops could be done in 4 cycles.
Well the indexed addressing is going to be a killer for MoCog what with having to decode the post byte bits and then having to fetch one or two offset bytes and then maybe having to indirect the resulting address.
We may end up with MUL being one of the fastest ops instead of the slowest.
But then in theory a 6809 program will require fewer instructions than say a 8085 program.
Ah well, we'll see.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
As I have said many times, and will keep saying, that's enough emulations for me. I'm told there are other interesting things to do with a Prop[noparse]:)[/noparse] 8088 is definitely out I did enough work with the real ones to have developed a loathing for them. Someone else is already on the 6502 case though.
MoCog is going to be real tight on space. Unlike the Z80 I have yet to see I nice way of dumping a lot of little used features into overlays.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Cluso (or anyone), there is no idea of an I/O memory space in the 6809, no OUT or IN instructions. Which means that technically we should check every memory reference in case it is actually an I/O device so we can trap out to the I/O device emulation. This will slow the emulator a bit and just seems clunky to me as it makes holes in the memory space.
What about we add IN and OUT to the instruction set? There are plenty of unused op-codes to use for it. Given that any OS we run on this will need it's I/O routines customizing this would not be a problem.
Also we have the TriBlade external RAM/SD card tweaks already from the ZiCog IN and OUT code.
Also we have IN and OUT as overlays already so it costs zero LONGS[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater: I hadn't thought of that. It makes sense to use seperate instructions to trap it.
The Motorola family always did memory mapped I/O. Usually, it was one end of the memory. However, it is always a block of memory allocated to I/O so it could be tested, but of course adds to the execution time per instruction emulated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Why not have one start up Variable with memory block to give emulator for its IO adresses.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha: Not a bad idea. Other possibility is to use #ifdefs as we are making heavy use if BST /HomeSpun now.
It just pains me to put a test for I/O access into the critical path. Perhaps I worry too much.
I'm leaning toward the idea of using #ifdefs to compile in/out the normal I/O access check and/or the new IN/OUT instructions. If Hitachi can throw a bunch of new instructions into their version of the 6809 I don't see why we can't take some liberties as well.
I've just been looking at the output of a C compiler for the 6809.
~50% of the instructions are loads and stores (LD?? ST??)
~15% is "load effective address" (LEA?)
~6% is short branches (B??)
~5% is push (PUSH?)
~4% is register transfers (TFR)
Actual "work" instructions like ADD, SUB CMP etc are only using 2% or 3%
Surprisingly arithmetic shift left and rotate left come in at nearly 5% each. They of course don't exist as operators in C but seem to be used as a fast multiply by two a lot.
So it seems to me I could handle most of the arithmetic/logic instructions with overlays with a minimal performance hit. I really need the space.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
My idea was to have variable that man fill with start of Emulator before MoCog starts.
It is always same adress bank You will use with one emulation start
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Here is the mid summer madness release of MoCog. Version 0.4.
This release now runs a gcc compiled version of "Hello world". There is no output at the moment as no kind of I/O is implemented yet but if you single step through the program and follow it carefully you can see it trying to output the text in the conio routine..
New here:
1. Pretty much all op-codes are implemented.
3. MUL, PSHS, PSHU,PULS, PULU, DAA, TFR, EXG are moved to overlays.
To do:
1. Get all the flag settings implemented.
3. DAA, TFR, EXG, Long branches and a few other odds and sods.
4. Get CUBIX running !!
I'm hoping to use the same console and disk I/O drivers as for the ZiCog CP/M to save reinventing the wheel.
P.S. I said some where that turning on optimizations in GCC for 6809 produced non-functional code. In fact it works fine, it was my buggy code that it optimized away to do nothing which was correct! Turning on O3 reduces the hello world program by about 50% in code size.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Anyway I am now releasing version 0.5. It is attached to the first post in this thread.
What's new:
1. All op-codes are now in place save a few things to do with hardware interrupts which may never be implemented.
3. I have "enhanced" the instruction set with an OUT instruction. This gives the 6809 an I/O space which saves having to check every memory read/write for memory mapped I/O devices.
4. The included 6809 "Hello world" program now uses that OUT op.
5. If you replace the SINGLE_STEP define with HEARTBEAT it will print "Hello world" to the console and then show that it is executing a "branch self" loop 500,000 times per second. Don't be fooled, most ops are MUCH slower[noparse]:([/noparse]
To be done:
1. Most ops do not set flags yet and the ones that do do not set all flags. Just enough to get the "Hello world" to run.
2. Testing, testing, testing...
A call for help:
Clusso, any chance you could check this out on the TriBlade for external RAM? The is only 50 or so LONGS left in the COG and I think ~26 of them will be needed for XMM. I'd like to have that fixed exactly before proceeding.
If anyone can find a way to shrink some of the ops I would be very happy. Things like EXG and TFR are complicated and huge and slow. Doubly so as I had to put them into overlays.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater - great news.
I would love to check it out but am flat out at the moment (still!!)·· As soon as I get time I will do this.
I am sure we can at least shrink some of the code and implement some speedups too, but that can come later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
@Cluso: That would be great, no blazing hurry, I have lots of real work I should be doing so this will have to rest for a bit anyway.
The big killers are any ops that have a post-byte.
The PUSHES and POPS have can push/pop from zero to 8 regs in one go depending on bits set in the post byte. This takes a lot of decoding and then doing(or not). Would be great if say GCC used it to push many regs but normally it's only one or two.
Transfer (TFR) and exchange (EXG) have a post byte specifying regs to move which again takes a lot of code to decode and check for valid moves etc.
Anything to do with the indexed addressing mode takes a lot of post byte decoding and is huge.
Sadly I've had to put these things into overlays (except indexing) and make them doubly slow. They could be decoded by dispatch tables but tables eat a lot of space and there is no room in the COG to put more code to dispatch to!
Perhaps all this code should go into a second cog for full speed execution. Looking at it the overheads of COG swapping in this case are not so bad compared to the Z80 case.
When I get a chance I think the next thing is trying to fix the flag settings and get Motorola's assist09 debug monitor running.
So far I have yet to find a nice instruction set exerciser to test this with like EX80 for the Z80.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@heater: yes once you have it running, even though slow and in overlays, I can help you look at it with another set of eyes to find some commonality.
When I did the spin interpreter, I had to shift it into overlays so that I could improve sections, after which I found I could move it all back in without overlays. Now, I know that will not be possible, but there are potential ways we could pass certain sections to other cogs to process bits. And if we are using a seperate prop to just do the processing with sram and uSD, then we have 6 cogs available in total (one will be required to implement the serial protocol to another prop, and another to do the SD interface which thinking about it could be an overlay anyway).
As for testing, maybe someone who has implemented 6809 in an FPGA may have some test routines.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Finally found a 6809 instruction set exerciser program. Written by W. Schwotzer in 2003 for the FlexEmu 6809 emulator that runs the Flex9 operating system.
In MoCog v0.6 I have modified mocog_demo to load a slightly modified version of the test as a file into the 6809 RAM.
So far all the addressing mode tests pass !!!
NEG and COM ops will pass if single stepped but not at full speed, very mysterious. The test loaded in this release has all tests that fail commented out. Just as I like to see "All tests succeed" [noparse]:)[/noparse]
MoCog version V0.6 is added to the first post.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thanks Ale. As it happens I already made my mul as a loop.
Currently mul is in an overlay so unrolling the loop would eat time in having to load a bigger overlay. So I coded it with #ifdef to produce a rolled or unrolled loop as required.
My loop is only 3 pasm ops instead of 4 in the interpreter.spin. Hope it works the same[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
What am I saying? My mul should not work the same. It is only an 8 bit by 8 bit unsigned multiply with a 16 bit result. Might be useful to others though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
tried to compile mocog with BST. I used the demo-board define. But every time I tried it, BST hang up.
BST Version 0.17
Compiler Version 0.1.3
has anybody the same effect?
Absolutely. That old version of bst predates the compiler supporting #define. Also, it had a really neat bug that causes it to lock up if you do try and use it [noparse]:)[/noparse]
Suggest you grab the latest release 0.18.2
Chris: I have been using BST 0.18.2 for a long time to compile MoCog.
Do you have, for example, PROP_DEMO_BOARD and HEARTBEAT set as defines in the project options?
Along with Project->Project Options->Optimizations->"Non-Parallax compatible extensions".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I downloaded your code (again) and read it and got some ideas for a possible (and future) 68K emulator. I think it may just be possible using a similar technique to the one you use but using LMM instead of overlays, It would depend on how long the ovr copy takes compared to how much is gained. I think it could just be feasible (read: no very nightmarish ): the point would be to fit all addressing modes load/store in COG RAM and having LMM for some opcodes, maybe MOVs should just be COG pasm. I do not know at this time. There are plenty of registers, and trap vectors...
The use of 2 "jump addresses" inside one long in the tables is quite smart.
Ale: "The use of 2 "jump addresses" inside one long in the tables is quite smart."
That whole idea is not mine but down to Cusso. It was a very nice fit for the Z80 simulator. In that case having the op-code decoding mostly done in the dispatch tables gained a lot of speed and saved COG space. A lot of Z80 ops are never used (in the CP/M world anyway) so who cares if they get farmed out to slower overlays or LMM?
Just now it is not working so well for the 6809 where there are no ops we can ignore and the indexed addressing modes eat a lot of time and space to decode.
I have to say, just now I'm all burned out for this emulator business.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
I'm starting to worry about the performance of MoCog.
A lot of 6809 op/addressing mode combinations took 4, 5, or 6 cycles. Most indexed addressing mode ops could be done in 4 cycles.
Well the indexed addressing is going to be a killer for MoCog what with having to decode the post byte bits and then having to fetch one or two offset bytes and then maybe having to indirect the resulting address.
We may end up with MUL being one of the fastest ops instead of the slowest.
But then in theory a 6809 program will require fewer instructions than say a 8085 program.
Ah well, we'll see.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
V0.3 Has all 6809 indexed addressing modes working and a MUL instruction.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
MoCog is going to be real tight on space. Unlike the Z80 I have yet to see I nice way of dumping a lot of little used features into overlays.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
What about we add IN and OUT to the instruction set? There are plenty of unused op-codes to use for it. Given that any OS we run on this will need it's I/O routines customizing this would not be a problem.
Also we have the TriBlade external RAM/SD card tweaks already from the ZiCog IN and OUT code.
Also we have IN and OUT as overlays already so it costs zero LONGS[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The Motorola family always did memory mapped I/O. Usually, it was one end of the memory. However, it is always a block of memory allocated to I/O so it could be tested, but of course adds to the execution time per instruction emulated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Why not have one start up Variable with memory block to give emulator for its IO adresses.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
It just pains me to put a test for I/O access into the critical path. Perhaps I worry too much.
I'm leaning toward the idea of using #ifdefs to compile in/out the normal I/O access check and/or the new IN/OUT instructions. If Hitachi can throw a bunch of new instructions into their version of the 6809 I don't see why we can't take some liberties as well.
I've just been looking at the output of a C compiler for the 6809.
~50% of the instructions are loads and stores (LD?? ST??)
~15% is "load effective address" (LEA?)
~6% is short branches (B??)
~5% is push (PUSH?)
~4% is register transfers (TFR)
Actual "work" instructions like ADD, SUB CMP etc are only using 2% or 3%
Surprisingly arithmetic shift left and rotate left come in at nearly 5% each. They of course don't exist as operators in C but seem to be used as a fast multiply by two a lot.
So it seems to me I could handle most of the arithmetic/logic instructions with overlays with a minimal performance hit. I really need the space.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
My idea was to have variable that man fill with start of Emulator before MoCog starts.
It is always same adress bank You will use with one emulation start
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
This release now runs a gcc compiled version of "Hello world". There is no output at the moment as no kind of I/O is implemented yet but if you single step through the program and follow it carefully you can see it trying to output the text in the conio routine..
New here:
1. Pretty much all op-codes are implemented.
3. MUL, PSHS, PSHU,PULS, PULU, DAA, TFR, EXG are moved to overlays.
To do:
1. Get all the flag settings implemented.
3. DAA, TFR, EXG, Long branches and a few other odds and sods.
4. Get CUBIX running !!
I'm hoping to use the same console and disk I/O drivers as for the ZiCog CP/M to save reinventing the wheel.
P.S. I said some where that turning on optimizations in GCC for 6809 produced non-functional code. In fact it works fine, it was my buggy code that it optimized away to do nothing which was correct! Turning on O3 reduces the hello world program by about 50% in code size.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Anyway I am now releasing version 0.5. It is attached to the first post in this thread.
What's new:
1. All op-codes are now in place save a few things to do with hardware interrupts which may never be implemented.
3. I have "enhanced" the instruction set with an OUT instruction. This gives the 6809 an I/O space which saves having to check every memory read/write for memory mapped I/O devices.
4. The included 6809 "Hello world" program now uses that OUT op.
5. If you replace the SINGLE_STEP define with HEARTBEAT it will print "Hello world" to the console and then show that it is executing a "branch self" loop 500,000 times per second. Don't be fooled, most ops are MUCH slower[noparse]:([/noparse]
To be done:
1. Most ops do not set flags yet and the ones that do do not set all flags. Just enough to get the "Hello world" to run.
2. Testing, testing, testing...
A call for help:
Clusso, any chance you could check this out on the TriBlade for external RAM? The is only 50 or so LONGS left in the COG and I think ~26 of them will be needed for XMM. I'd like to have that fixed exactly before proceeding.
If anyone can find a way to shrink some of the ops I would be very happy. Things like EXG and TFR are complicated and huge and slow. Doubly so as I had to put them into overlays.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I would love to check it out but am flat out at the moment (still!!)·
I am sure we can at least shrink some of the code and implement some speedups too, but that can come later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
The big killers are any ops that have a post-byte.
The PUSHES and POPS have can push/pop from zero to 8 regs in one go depending on bits set in the post byte. This takes a lot of decoding and then doing(or not). Would be great if say GCC used it to push many regs but normally it's only one or two.
Transfer (TFR) and exchange (EXG) have a post byte specifying regs to move which again takes a lot of code to decode and check for valid moves etc.
Anything to do with the indexed addressing mode takes a lot of post byte decoding and is huge.
Sadly I've had to put these things into overlays (except indexing) and make them doubly slow. They could be decoded by dispatch tables but tables eat a lot of space and there is no room in the COG to put more code to dispatch to!
Perhaps all this code should go into a second cog for full speed execution. Looking at it the overheads of COG swapping in this case are not so bad compared to the Z80 case.
When I get a chance I think the next thing is trying to fix the flag settings and get Motorola's assist09 debug monitor running.
So far I have yet to find a nice instruction set exerciser to test this with like EX80 for the Z80.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
When I did the spin interpreter, I had to shift it into overlays so that I could improve sections, after which I found I could move it all back in without overlays. Now, I know that will not be possible, but there are potential ways we could pass certain sections to other cogs to process bits. And if we are using a seperate prop to just do the processing with sram and uSD, then we have 6 cogs available in total (one will be required to implement the serial protocol to another prop, and another to do the SD interface which thinking about it could be an overlay anyway).
As for testing, maybe someone who has implemented 6809 in an FPGA may have some test routines.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
members.optusnet.com.au/jekent/system09/index.html
No responses yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
In MoCog v0.6 I have modified mocog_demo to load a slightly modified version of the test as a file into the 6809 RAM.
So far all the addressing mode tests pass !!!
NEG and COM ops will pass if single stepped but not at full speed, very mysterious. The test loaded in this release has all tests that fail commented out. Just as I like to see "All tests succeed" [noparse]:)[/noparse]
MoCog version V0.6 is added to the first post.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Here it is.
The mul can be a loop, you have 11 cycles after all, 11 1 or 2 MHz cycles
It is a pity they based the HC11 on the 6801/03 and not on the 09 :-(. Life would have been better (when I used to program for those uCs... long ago),
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Currently mul is in an overlay so unrolling the loop would eat time in having to load a bigger overlay. So I coded it with #ifdef to produce a rolled or unrolled loop as required.
My loop is only 3 pasm ops instead of 4 in the interpreter.spin. Hope it works the same[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
tried to compile mocog with BST. I used the demo-board define. But every time I tried it, BST hang up.
BST Version 0.17
Compiler Version 0.1.3
has anybody the same effect?
Absolutely. That old version of bst predates the compiler supporting #define. Also, it had a really neat bug that causes it to lock up if you do try and use it [noparse]:)[/noparse]
Suggest you grab the latest release 0.18.2
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
thanks for that. I downloaded the new version. It doesn't hang up but it seems not to know the
#else
directive..
Do you have, for example, PROP_DEMO_BOARD and HEARTBEAT set as defines in the project options?
Along with Project->Project Options->Optimizations->"Non-Parallax compatible extensions".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I downloaded your code (again) and read it and got some ideas for a possible (and future) 68K emulator. I think it may just be possible using a similar technique to the one you use but using LMM instead of overlays, It would depend on how long the ovr copy takes compared to how much is gained. I think it could just be feasible (read: no very nightmarish
The use of 2 "jump addresses" inside one long in the tables is quite smart.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
That whole idea is not mine but down to Cusso. It was a very nice fit for the Z80 simulator. In that case having the op-code decoding mostly done in the dispatch tables gained a lot of speed and saved COG space. A lot of Z80 ops are never used (in the CP/M world anyway) so who cares if they get farmed out to slower overlays or LMM?
Just now it is not working so well for the 6809 where there are no ops we can ignore and the indexed addressing modes eat a lot of time and space to decode.
I have to say, just now I'm all burned out for this emulator business.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.