Snow, did someone mention snow. We used to ski every 2nd weekend in season (it's short in OZ) when the kids were younger.
Oh, and do you have neck problems - from wearing that heavy helmet!
Anyway, welcome back Drac. You only have 5,000 threads to catch up on!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I had the settings for my (rather complex) camera wrong and didn't have the manual with me to to sort them out. I worked out what I should have been doing on the way back on the train.
I should get some better shots at this year's show, next month. I'll set the camera up before I go.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Since no one applied for a patent (which was my intent in publishing) the only real say I have at this point is based on the community goodwill I've gathered with my contributions and by my helping people; although I think i could win a case in West Texas [noparse]:)[/noparse] if I were silly enough to file one. Good people always provide the credit I ask for; a few good people had just forgot due to being busy, which is why I had not pestered them - they will eventually realize and provide credit.
Dr_Acula - welcome back - please noooooo HMM - heater meant it as a jest! LMM has been LMM since '06, let's not confuse newbies [noparse]:)[/noparse]
Now, back to the original purpose at hand:
Heater's example in the ZOG thread has convinced me that there is much to be said for using C++ static features, in which case, it really can generate very good code.
Dr_Acula said...
I'm fascinated by the serial ram solution. I need to catch up where this has progressed to - is it possible to fit the driver code in a single cog along with the raw HMM driver code to run C?
I'll look at porting Catalina to run out of EEPROM later since it offers running bigger programs than Spin with simple hardware. Size is more important than performance as long as performance is adequate ... we'll see one way or another.
I'd bet Bill will look at running Catalina using PropCade's SPI RAM.
Christof Eb. said...
Hi, to the compiler specialists,
as far as I understand, part of the discussion is about the fact, that LMM code needs more hub ram space than bytecode does.
What do you think of a "CMM - Compact Memory Model":
32 bit for one instruction is very luxerious. 18bits are just adresses.
The idea ist, that the CMM-loop fetches a long and checks bit 17. If it is set, the long is a normal instruction and is executed directly. Bit 17 is chosen, because I assume, that the variables are located in the upper half of cog ram.
If the bit is not set, the long is split into two instructions, which consist of 6bits instruction and 8 bit source adress +1bit??? As destination always the same "accumulator register" is used. I don't know, perhaps it is better to have a register set of 8 registers and to use 3bit source and 3bit destination. I think, that you don't need conditions too often. How many extra cycles would you need to split the long into the 2 instructions? - I am quiet sure, that there is still an advantage over spin speed left? Perhaps 3 instructions could be squeezed into 32 bits?
Christof
I have prototyped a 16 bits instruction set CMM. I think the fetch-decode-execute time is ~20 instructions but only ~8 or so for some of the commonly used ones. Since the commercial ROI is not clear, we have not moved forward with this V2 plan.
Welcome back! I'd love to go and have a look at a "real" Catalina one day!
Yes, Catalina (the program) can compile programs for the DracBlade, using a flat memory model for the 512K SRAM. The only issue with the DracBlade is that I find when running large C programs that I can't use the VGA in HiRes mode because it consumes too much of the Hub RAM - but in LoRes VGA mode evrything is fine.
You're welcome to use Catalina's XMM kernel (and LMM/XMM "promitives") for your own purposes. However, I don't think it will be possible to fit a serial RAM driver in the same cog as Catalina's XMM kernel. I think it will need a separate cog, and then of course you need some way of passing the resulting LONGs to/from the XMM kernel (and doing so will occupy the space currently consumed by the SRAM access routines).
@leon,
Nice pictures!
@jazzed,
I was going to do some messing around with executing code from SPI RAM/EEPROM but I'm happy for you to do so - if you need any help let me know. I have heard estimates that executing from SPI would be at least 10x slower than executing from Hub, but I suppose in some circumstances it might still be useful. Since I believe you will need to dedicate a cog for the SPI driver, I was thinking it might be useful to try and also implement a cache in that cog to try and speed things up - but this might be so complex to implement it could end up just making things worse!
@Christof,
I'm with Richard - while a "compact memory model" it could be implemented, I can't see it being worthwhile. Especially not with the Prop II on the horizon. Any applications large enough to justify the "compact" mode could simply be better done with the Prop II. Or (heresy alert!) with another micro.
@heater
I haven't read your article in detail yet, but I do agree that if you limit youself to a subset of C++ then it can be useful in an embedded application. I also think there might be benefit in "formalizing" such a subset - i.e. one that uses the nice things of C++ but omits the "expensive" C++ features (similar in some ways to what SPARK does to Ada). Unfortunately, this has been attempted before and the resulting languages simply don't seem to get used. C is just too cheap and just too pervasive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I was going to do some messing around with executing code from SPI RAM/EEPROM but I'm happy for you to do so - if you need any help let me know. I have heard estimates that executing from SPI would be at least 10x slower than executing from Hub, but I suppose in some circumstances it might still be useful.
I have a COG object that manages cache and fetches from EEPROM with a 2 long mailbox interface if you want to look at it. Your code fetch LMM loop should be pretty easy to find and replace though. So ... I can build Catalina on Linux right? I finally gave Bill Gates and his Vista Smile the boot.
Once I get VMCOG to handle larger virtual spaces, it might be interesting to modify the Catalina kernel to use VMCOG - which has SPI ram drivers [noparse]:)[/noparse]
My microcode analogy was more about the various LMM "primitives" that you choose to implement in your "big cog" LMM kernel. For example, the Catalina kernel implements a single LMM PASM instruction that can push up to 24 cog registers onto the stack (and another that can restore them all).
@Ross and Richard,
glad to hear that the idea of CMM is not too silly after all. I came to it, when I played a little bit with SmallC for the Prop. SmallC only uses a first and a second register.
I do think too, that the benefit is not too often too great. As a matter of fact, I have never been running out of code space, but I would like to have more data ram sometimes. If this happens, the hub ram should be much greater, so the advantage of a little more compact code is not so big. Nevertheless, hub ram is already there and already payed for, so sometimes it would be nice to stay in one language and one compiler and it would be nice if you could just write "Program " for cog code, "Program LMM" for LMM code and "Program CMM" for Compact Code. (Bean, if you read this, my prioritiy for PropBasic would still be first float and several operations in one line...)
Nice weekend!
Christof
Yes, you can build Catalina on Linux. You need gcc, bison & flex installed to build it (you may also need yacc IIRC), and mono installed to run it. Email me or your EEPROM cog object (or post it here) and I'll have a look at it. I can probably quickly tell you whether it will fit in the kernel "as is" or will need another cog.
@Bill,
Yes, I'll try and get some time in the next week or so to have a look at VMCog. This week my priority is to finish off the Catalina Code Optimizer.
So much to do, and so little time!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
[noparse][[/noparse]quote=RossH]
I haven't read your article in detail yet, but I do agree that if you limit youself to a subset of C++ then it can be useful in an embedded application. I also think there might be benefit in "formalizing" such a subset - i.e. one that uses the nice things of C++ but omits the "expensive" C++ features (similar in some ways to what SPARK does to Ada). Unfortunately, this has been attempted before and the resulting languages simply don't seem to get used. C is just too cheap and just too pervasive.
Yep, I thought about SPARK ADA as well.
Limiting C++ to "safe" subset is exactly what the Arduino guys have done. They have done it by not telling anyone about them. When you start from zero knowledge of programming on the Arduino and read the docs/tutorials there is no mention of C or C++. No, they call the language "wiring" or whatever. They document the language features you need to know and nothing more. So the idea of using new/delete or exceptions or templates or whatever would never occur to you.
There is no checking the tools to keep you in line, only your ignorance saves you[noparse]:)[/noparse]
Well, apart from those features that won't compile due to the lack of libstc++.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
Oh, and do you have neck problems - from wearing that heavy helmet!
Anyway, welcome back Drac. You only have 5,000 threads to catch up on!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
www.flickr.com/photos/79459751@N00/sets/72157624515010706/
I had the settings for my (rather complex) camera wrong and didn't have the manual with me to to sort them out. I worked out what I should have been doing on the way back on the train.
I should get some better shots at this year's show, next month. I'll set the camera up before I go.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/16/2010 4:35:25 PM GMT
Since no one applied for a patent (which was my intent in publishing) the only real say I have at this point is based on the community goodwill I've gathered with my contributions and by my helping people; although I think i could win a case in West Texas [noparse]:)[/noparse] if I were silly enough to file one. Good people always provide the credit I ask for; a few good people had just forgot due to being busy, which is why I had not pestered them - they will eventually realize and provide credit.
Dr_Acula - welcome back - please noooooo HMM - heater meant it as a jest! LMM has been LMM since '06, let's not confuse newbies [noparse]:)[/noparse]
Now, back to the original purpose at hand:
Heater's example in the ZOG thread has convinced me that there is much to be said for using C++ static features, in which case, it really can generate very good code.
GCC never ceases to amaze me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I'd bet Bill will look at running Catalina using PropCade's SPI RAM.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
You are right, of course.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I have prototyped a 16 bits instruction set CMM. I think the fetch-decode-execute time is ~20 instructions but only ~8 or so for some of the commonly used ones. Since the commercial ROI is not clear, we have not moved forward with this V2 plan.
Welcome back! I'd love to go and have a look at a "real" Catalina one day!
Yes, Catalina (the program) can compile programs for the DracBlade, using a flat memory model for the 512K SRAM. The only issue with the DracBlade is that I find when running large C programs that I can't use the VGA in HiRes mode because it consumes too much of the Hub RAM - but in LoRes VGA mode evrything is fine.
You're welcome to use Catalina's XMM kernel (and LMM/XMM "promitives") for your own purposes. However, I don't think it will be possible to fit a serial RAM driver in the same cog as Catalina's XMM kernel. I think it will need a separate cog, and then of course you need some way of passing the resulting LONGs to/from the XMM kernel (and doing so will occupy the space currently consumed by the SRAM access routines).
@leon,
Nice pictures!
@jazzed,
I was going to do some messing around with executing code from SPI RAM/EEPROM but I'm happy for you to do so - if you need any help let me know. I have heard estimates that executing from SPI would be at least 10x slower than executing from Hub, but I suppose in some circumstances it might still be useful. Since I believe you will need to dedicate a cog for the SPI driver, I was thinking it might be useful to try and also implement a cache in that cog to try and speed things up - but this might be so complex to implement it could end up just making things worse!
@Christof,
I'm with Richard - while a "compact memory model" it could be implemented, I can't see it being worthwhile. Especially not with the Prop II on the horizon. Any applications large enough to justify the "compact" mode could simply be better done with the Prop II. Or (heresy alert!) with another micro.
@heater
I haven't read your article in detail yet, but I do agree that if you limit youself to a subset of C++ then it can be useful in an embedded application. I also think there might be benefit in "formalizing" such a subset - i.e. one that uses the nice things of C++ but omits the "expensive" C++ features (similar in some ways to what SPARK does to Ada). Unfortunately, this has been attempted before and the resulting languages simply don't seem to get used. C is just too cheap and just too pervasive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Thanks,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Once I get VMCOG to handle larger virtual spaces, it might be interesting to modify the Catalina kernel to use VMCOG - which has SPI ram drivers [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
The more uses... the merrier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
____________________________________________________________________
Post Edited By Moderator (Dave Andreae (Parallax)) : 7/19/2010 9:59:13 PM GMT
glad to hear that the idea of CMM is not too silly after all. I came to it, when I played a little bit with SmallC for the Prop. SmallC only uses a first and a second register.
I do think too, that the benefit is not too often too great. As a matter of fact, I have never been running out of code space, but I would like to have more data ram sometimes. If this happens, the hub ram should be much greater, so the advantage of a little more compact code is not so big. Nevertheless, hub ram is already there and already payed for, so sometimes it would be nice to stay in one language and one compiler and it would be nice if you could just write "Program " for cog code, "Program LMM" for LMM code and "Program CMM" for Compact Code. (Bean, if you read this, my prioritiy for PropBasic would still be first float and several operations in one line...)
Nice weekend!
Christof
Yes, you can build Catalina on Linux. You need gcc, bison & flex installed to build it (you may also need yacc IIRC), and mono installed to run it. Email me or your EEPROM cog object (or post it here) and I'll have a look at it. I can probably quickly tell you whether it will fit in the kernel "as is" or will need another cog.
@Bill,
Yes, I'll try and get some time in the next week or so to have a look at VMCog. This week my priority is to finish off the Catalina Code Optimizer.
So much to do, and so little time!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I haven't read your article in detail yet, but I do agree that if you limit youself to a subset of C++ then it can be useful in an embedded application. I also think there might be benefit in "formalizing" such a subset - i.e. one that uses the nice things of C++ but omits the "expensive" C++ features (similar in some ways to what SPARK does to Ada). Unfortunately, this has been attempted before and the resulting languages simply don't seem to get used. C is just too cheap and just too pervasive.
Yep, I thought about SPARK ADA as well.
Limiting C++ to "safe" subset is exactly what the Arduino guys have done. They have done it by not telling anyone about them. When you start from zero knowledge of programming on the Arduino and read the docs/tutorials there is no mention of C or C++. No, they call the language "wiring" or whatever. They document the language features you need to know and nothing more. So the idea of using new/delete or exceptions or templates or whatever would never occur to you.
There is no checking the tools to keep you in line, only your ignorance saves you[noparse]:)[/noparse]
Well, apart from those features that won't compile due to the lack of libstc++.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hey, that's the same plane that is in that old musical "South Pacific"
I really like the musical numbers in that movie.
I have it right here on my laptop's HD
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM