Yeah, during a period of unemployment I got stuck into reading some old old books about the history of the development of the steam engine. I was totally fascinated by their patent and licensing struggles. Amazed that I read the same stories about today. Just change "steam" to "silicon" or "software" and the arguments read the same.
The highlight of that research was a book on the history of steam boiler explosions. Well "history" it was written a hundred years ago. Wish I could find it again. This sort of thing makes me really popular at parties[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I don't want to speak for Bill, but I don't think he would seriously want to impede the use of LMM by others - he simply (and rightly) asks to be credited as the first one to apply the idea to the Propeller.
I also don't think there are any grounds for LMM to be patentable. LMM is just a one instruction code overlay, and I don't think you could patent the use of code overlays - there is plenty of prior art in this area (and also some existing patents held by IBM - so in fact we may already be in trouble!). Of course, if anybody knows better then feel free to let us know.
As for the Arduino (or now Bill's ProDuino!) - I think this is great. It will really help Parallax in the hobbyist domain, where I think it may indeed have been losing some ground to platforms like that. It will also encourage someone to port GCC. However, C++ may be attractive to hobbyists, but in the embedded domain it is simply a non-starter. Of course, GCC can be used for just plain old C as well, so it would still be beneficial.
Ross.
EDIT: Should have read the rest of the thread before commenting. Bill has explained his purposes and intentions regarding LMM quite succintly!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Bill,
Your comment below is basically where I take issue.
Credit is almost always in the fine print, at the bottom of an "About" box, etc., where exactly would you like the credit to be placed?
The request for one or two copies of any commercial product seems over the top.· What if GM wanted to use a prop as part of say an engine control device and they used a compiler that produces LMM code, would you like a pair of Corvettes?
I see LMM as being fundamental to using the prop in a lot of cases, and agree completely that the credit goes to you for formalizing the idea and getting it into the hands (and props) of the community.· I have no problem with calling it HMM as someone suggested.· I just think there needs to be a point where it is considered a fundamental way of coding for the prop that is freely available when used in the context of a prop chip.
BTW, I have no current plans to do anything with the prop, other than maybe the 1802 stuff, which won't need LMM anyway, so I don't have any hidden motivation.
Bill Henning said...
All I ever required from anyone was an acknowledgement in the code, and documentation for any product that uses LMM, but I do not want the acknowledgement to be buried in tiny unreadable print. I would also like a copy or two of any commercial product that uses LMM, more from a personal desire to see where my idea was taken than anything.
When I said... "I don't mean this as being disrespectful to Bill, he has obviously made a lot of contributions to the prop community, but at this point I think he is holding it back."
I should have said something more like "...but at this point his controlling attitude towards LMM may be holding it back.
My goal here is to get the community to think about how a potential commercial user might look at the prop and some of the potential IP barriers to using it.· To me this one would be a pretty big red flag to the legal department.
Although I don't consider LMM to be an overlay, more of a microcode execution mechanism [noparse]:)[/noparse] [noparse]:)[/noparse] [noparse]:)[/noparse]
I had quite a "WOW" moment when I came up with it; I'd been doing some indexing with self-modifying code, when it hit me - why not have a tight loop that modifies the instruction to be executed, based on the contents of the hub? Thus LMM was born...
The whole idea with LMM was to treat a cog as a microcode engine, and kernel routines as microcode extensions; implementing a classical register machine that happened to have a LOT of registers. FCACHE was an attempt to get most of the possible "microcode" speed back [noparse]:)[/noparse]
It is perfectly reasonable for me to ask for copies of compilers that generate LMM code, or other interesting LMM based applications.
Your Corvette engine controller argument is ludicrous. Your concerns and assumptions, in my opinion are unwarranted and baseless.
For your information, no matter how you try to frame it, I did not formalize the idea. How could I "formalize" something that did not exist?
I came up with it.
Perhaps someone would have come up with it a few months after I did. Perhaps no one would have come up with it for years. No one will ever know.
I did come up with it, and subsequently published to prevent submarine patents. I do ask for credit, as no matter how you try to phrase it, I did come up with it.
Had you come up with an enabling technology, and all you asked for was appropriate credit, I would have praised you, and gladly given credit in any project where I used your technique.
I guess we are different in one major respect. I like giving credit where it is due.
Bill
ctwardell said...
Bill,
Your comment below is basically where I take issue.
Credit is almost always in the fine print, at the bottom of an "About" box, etc., where exactly would you like the credit to be placed?
The request for one or two copies of any commercial product seems over the top. What if GM wanted to use a prop as part of say an engine control device and they used a compiler that produces LMM code, would you like a pair of Corvettes?
I see LMM as being fundamental to using the prop in a lot of cases, and agree completely that the credit goes to you for formalizing the idea and getting it into the hands (and props) of the community. I have no problem with calling it HMM as someone suggested. I just think there needs to be a point where it is considered a fundamental way of coding for the prop that is freely available when used in the context of a prop chip.
BTW, I have no current plans to do anything with the prop, other than maybe the 1802 stuff, which won't need LMM anyway, so I don't have any hidden motivation.
Bill Henning said...
All I ever required from anyone was an acknowledgement in the code, and documentation for any product that uses LMM, but I do not want the acknowledgement to be buried in tiny unreadable print. I would also like a copy or two of any commercial product that uses LMM, more from a personal desire to see where my idea was taken than anything.
When I said...
"I don't mean this as being disrespectful to Bill, he has obviously made a lot of contributions to the prop community, but at this point I think he is holding it back."
I should have said something more like "...but at this point his controlling attitude towards LMM may be holding it back.
My goal here is to get the community to think about how a potential commercial user might look at the prop and some of the potential IP barriers to using it. To me this one would be a pretty big red flag to the legal department.
I hereby award you TWO free copies of the Catalina C Compiler. You can download it (twice!) from catalina-c.sourceforge.net
You will find yourself suitably acknowledged in the Catalina Reference Manual. However, I draw the line at rewriting all the documenation to replace LMM with HMM!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Bill,
I never said credit was not due, I was just put off when you jumped in when someone called LMM "hub pasm".
Not sure how my argument is ludicrous, you are the one that said "any", and if it is just for curiousity then why two items.
I'm not here to argue with you, as you have determined we will never agree on this matter.
C.W.
Bill Henning said...
C.W.,
I suspect you and I will never agree.
It is perfectly reasonable for me to ask for copies of compilers that generate LMM code, or other interesting LMM based applications.
Your Corvette engine controller argument is ludicrous. Your concerns and assumptions, in my opinion are unwarranted and baseless.
For your information, no matter how you try to frame it, I did not formalize the idea. How could I "formalize" something that did not exist?
I came up with it.
Perhaps someone would have come up with it a few months after I did. Perhaps no one would have come up with it for years. No one will ever know.
I did come up with it, and subsequently published to prevent submarine patents. I do ask for credit, as no matter how you try to phrase it, I did come up with it.
Had you come up with an enabling technology, and all you asked for was appropriate credit, I would have praised you, and gladly given credit in any project where I used your technique.
I guess we are different in one major respect. I like giving credit where it is due.
Bill
ctwardell said...
Bill,
Your comment below is basically where I take issue.
Credit is almost always in the fine print, at the bottom of an "About" box, etc., where exactly would you like the credit to be placed?
The request for one or two copies of any commercial product seems over the top. What if GM wanted to use a prop as part of say an engine control device and they used a compiler that produces LMM code, would you like a pair of Corvettes?
I see LMM as being fundamental to using the prop in a lot of cases, and agree completely that the credit goes to you for formalizing the idea and getting it into the hands (and props) of the community. I have no problem with calling it HMM as someone suggested. I just think there needs to be a point where it is considered a fundamental way of coding for the prop that is freely available when used in the context of a prop chip.
BTW, I have no current plans to do anything with the prop, other than maybe the 1802 stuff, which won't need LMM anyway, so I don't have any hidden motivation.
Bill Henning said...
All I ever required from anyone was an acknowledgement in the code, and documentation for any product that uses LMM, but I do not want the acknowledgement to be buried in tiny unreadable print. I would also like a copy or two of any commercial product that uses LMM, more from a personal desire to see where my idea was taken than anything.
When I said...
"I don't mean this as being disrespectful to Bill, he has obviously made a lot of contributions to the prop community, but at this point I think he is holding it back."
I should have said something more like "...but at this point his controlling attitude towards LMM may be holding it back.
My goal here is to get the community to think about how a potential commercial user might look at the prop and some of the potential IP barriers to using it. To me this one would be a pretty big red flag to the legal department.
You came across as resenting my wanting credit, and I only jumped in about "hub pasm" as I did not want to confuse new users.
The two items is actually a good question. The reason is simple... many software products have a dongle, or a software lock. I change my computers often.
Bill
ctwardell said...
Bill,
I never said credit was not due, I was just put off when you jumped in when someone called LMM "hub pasm".
Not sure how my argument is ludicrous, you are the one that said "any", and if it is just for curiousity then why two items.
I'm not here to argue with you, as you have determined we will never agree on this matter.
C.W.
Bill Henning said...
C.W.,
I suspect you and I will never agree.
It is perfectly reasonable for me to ask for copies of compilers that generate LMM code, or other interesting LMM based applications.
Your Corvette engine controller argument is ludicrous. Your concerns and assumptions, in my opinion are unwarranted and baseless.
For your information, no matter how you try to frame it, I did not formalize the idea. How could I "formalize" something that did not exist?
I came up with it.
Perhaps someone would have come up with it a few months after I did. Perhaps no one would have come up with it for years. No one will ever know.
I did come up with it, and subsequently published to prevent submarine patents. I do ask for credit, as no matter how you try to phrase it, I did come up with it.
Had you come up with an enabling technology, and all you asked for was appropriate credit, I would have praised you, and gladly given credit in any project where I used your technique.
I guess we are different in one major respect. I like giving credit where it is due.
Bill
ctwardell said...
Bill,
Your comment below is basically where I take issue.
Credit is almost always in the fine print, at the bottom of an "About" box, etc., where exactly would you like the credit to be placed?
The request for one or two copies of any commercial product seems over the top. What if GM wanted to use a prop as part of say an engine control device and they used a compiler that produces LMM code, would you like a pair of Corvettes?
I see LMM as being fundamental to using the prop in a lot of cases, and agree completely that the credit goes to you for formalizing the idea and getting it into the hands (and props) of the community. I have no problem with calling it HMM as someone suggested. I just think there needs to be a point where it is considered a fundamental way of coding for the prop that is freely available when used in the context of a prop chip.
BTW, I have no current plans to do anything with the prop, other than maybe the 1802 stuff, which won't need LMM anyway, so I don't have any hidden motivation.
Bill Henning said...
All I ever required from anyone was an acknowledgement in the code, and documentation for any product that uses LMM, but I do not want the acknowledgement to be buried in tiny unreadable print. I would also like a copy or two of any commercial product that uses LMM, more from a personal desire to see where my idea was taken than anything.
When I said...
"I don't mean this as being disrespectful to Bill, he has obviously made a lot of contributions to the prop community, but at this point I think he is holding it back."
I should have said something more like "...but at this point his controlling attitude towards LMM may be holding it back.
My goal here is to get the community to think about how a potential commercial user might look at the prop and some of the potential IP barriers to using it. To me this one would be a pretty big red flag to the legal department.
Overlays were mentioned. My overlay technique/code has acknowledgements to the users who developed the reverse loop, etc. But what I wanted to say was that we were using overlays in 1974 but in fact the OS used overlays in the first code release way back in 1969. That was a Friden/Singer/ICL mini. Don't know about IBM - maybe they didn't know?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
RossH said...
...C++ may be attractive to hobbyists, but in the embedded domain it is simply a non-starter.
Why do you say so? C++ is fine on small embedded systems.
Perhaps you missed it but in the Zog thread Bill and I debated the use of C++ for small, memory limited, real-time embedded systems. There you will find example C++ code and the resulting compiler output which shows there is no downside to using C++.
I will not reproduce it the code here but it goes like this:
1) Imagne you want multiple instances of some functionality, a serial line protocol say, or a cyclic buffer, whatever.
2) In C you could cut and paste the code for one instance into another, renaming the funcs and vars so that it compiles. Then use both copies in your app. This is fast in execution but doubles the code space required.
3) Or in C you might get clever and have one copy of the code and multiple copies of the instance data using structs. This saves code space but now yo have to pass a pointer to every function so that it knows which instance you are working on at any moment.
4) Or you might use C++. Instantiate the required number of objects for you app satically. (not on the heap with new not on the stack). Here C++ takes care of thatinstance pointer for you.
Turns out that with GCC at least the generated code for 3) and 4) is almost exactly the same. That is C++ does neatly and automatically what you would do in C. The source code looks much nicer without all that pointer stuff.
In fact in all the examples I tried the C++ code came out a couple of bytes smaller.
On this discovery, which surprised me, I chose to use C++ in libzog and now find they have been doing it forever in Arduino land.
The point is to make use of C++ features that make your code easier to write and maintain and is generally prettier whilst staying away from it's features that make it memory hungry and slow.
Having worked on a number of embedded projects in the past that were using object oriented techniques in C I'm very glad this works so well in C++.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
My goal here is to get the community to think about how a potential commercial user might look at the prop and some of the potential IP barriers to using it. To me this one would be a pretty big red flag to the legal department.
I think you worry to much and you should get a new legal department.
If that department:
1) Understood programming
2) Had read all the code you and you colleagues write for the company
3) Knew every current relevant patent
Then they would probably never let you actually release anything for fear of being sued.
What we are talking about here is 4 lines of assembler basically. That's unlikely to be enforceable as a patent given all the prior art of overlays, self-modifying code etc etc going back to the dawn of computing.
As for copyright, I seriously doubt it has a case.
Reality is that Bill has no say in this at all. But he has done the Prop community a great service by publishing the idea which is now used by Catalina and ICC C compilers which may never have existed or been slower coming without it. I'm sure LMM is used in other places to, heck I even wrote my own small language compiler to use it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm not saying C++ can't be used. I'm not even saying it shouldn't be used. I'm saying it simply doesn't get used - at least not very much!
This has been discussed several times in several other threads. The statistics are simply irrefutable. C++ gained a small amount of traction in embedded work a few years ago (when it was all the rage in other domains) but it never made it anywhere near the top of the list, and has been on the decline ever since (I'm sorry, I can't quote the figures offhand - but I have quoted them in other threads, and they are easy enough to find if you look).
Actually, even the raw figures don't tell the full story since I know they include some companies that claim to use C++ when all they really do is use a C++ compiler but limit themselves to a subset of the language that is little more than plain old C anyway (I have worked for such a company). This is perfectly understandable - I think what you found in the Zog thread was that C++ compilers are often better at compiling simple C than C compilers - but this is just a reflection that there is little incentive for C compilers to strive for much more efficiency than they reached quite a few years ago, whereas C++ compilers absolutely continue to have to do so!
You also have to keep in mind that when people say "embedded" they often mean nothing more than a headless PC. Of course if you have a gigabyte of RAM, a terabyte of disk and a multicore gigahertz processor then you might consider writing your embedded application in C++. You can even run it on Windows or Unix and still call it embedded - but this isn't really the same as the type of embedded application for which a Propeller would be an appropriate choice.
There are also various technical reasons why C++ is not particularly suitable for embedded work, and these are explored in depth in many places. Two simple examples: you generally find it isn't a good idea to use things like exceptions or templates (which rules out the entire STL) in an embedded application.
I'm not against C++ - I have also developed "embedded" applications in C++ (of the "Unix" variety). And I have also thought for a while that there is room for a language that is as efficient as C but which removes some of the C "gotchas", adds some of the C++ "niceties" but omits the C++ "gotchas" (and C++ has more bizarre "gotchas" than C ever did!). But unfortunately "there just ain't no such animal" - and if there were it probably wouldn't get used anyway!
Given a choice between C and anything, most embedded companies still choose C. Why wouldn't they? - C is cheap, fast, does the job required, requires no training, is future proof, and runs on every microproessor/microcontroller they currently use or may ever choose to use. This combination is pretty hard for any other language to beat.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
@RossH, I think it depends on how limited your definition of "embedded work". C++ gets used quite extensively in mobile phones and PDAs, especially the smartphones, but I guess you don't consider those embedded? It's also pretty dominant in portable gaming devices using arm and mips architectures (gameboy, DS, PSP).... oh those aren't embedded either, I bet, by your definition...
I think your definition of embedded is a more limited subset than what others (myself included) might define it as...
Most likely if you don't limit embedded to only mean tiny MCUs with extremely limited resources then you might find that C++ suddenly becomes the overwhelming giant elephant in the room.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
True but I don't care. If statistics of other peoples behaviour we so important to me then I should not be using a Propeller but a PIC or AVR. Heck I'd probably have spent the last month glued to the TV watching football.
RossH said...
I think what you found in the Zog thread was that C++ compilers are often better at compiling simple C than C compiler...
No that's not what I found. What I found was that using C++ in a way that makes sense for a memory constrained system generates exactly the same code as using an object oriented approach in C.
So for example in C I might have multiple instances of some object defined by a struct and some functions. To use that object I write:
aFunction (anInstancePointer, parm1, parm2);
where "anInstancePointer" selects the data for the instance I want to work on.
Both those calls generate exactly the same code, barring difference in some immediate values.
This was a surprise even to me having used C for embedded systems for years and having seen how bloaty a C++ program can become on a PC.
Now there are many other C++ features one could use with no overhead over C. For example say I want cyclic buffers. In C I might write one for chars and one for ints etc. In C++ I could use templates to get those from the same source with no overhead. And so on. I'm not done with exploring this yet.
My conclusion is that embedded engineers have never really been learned how to use C++ efficiently. Of course if your code starts filling up with new/delete and string and the C++ standard library you are in trouble. It's not their fault, C++ is never presented in the context of small systems, check any beginners tutorial.
The Arduino guys learned this and use it very well it seems.
RossH said...
...technical reasons why C++ is not particularly suitable for embedded work...you generally find it isn't a good idea to use things like exceptions or templates (which rules out the entire STL) in an embedded application.
I agree exceptions are a disaster for embedded. Actually I don't like them anywhere.
The STL is obviously out. But then so is any huge library in any language if you don't have the space. In embedded work I want all my memory usage under my control. So most of STL is not relevant anyway.
Not sure template should be written off so easily. Using them to generate code operating on different types seems safe enough to me. I have to experiment with some simple use of templates.
You make a good point about portability of C++. Until C++ is available for every little chip its a risky proposition in that respect. But hey isn't GCC available for everything that's important any way?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Actually no I don't think mobile phones and PDA are embedded systems. Especially not nowadays. I've just order myself a Android based phone. 1GHz processor, 512M RAM, 2GB ROM 32GB SD card. High res display and programmable by me. That exceeds the spec of the PC I was using 5 years ago by 10 or more in all numbers. Perhaps there are still some "normal" phones around that I might call embedded systems.
Same applies to gaming systems nowadays.
Now my point is that "embedded system" is not defined by how big it is physically, how fast it's processor is, how much memory it's got etc etc.
No, where I come from an "embedded system" was some compute platform that performed whatever task, say machine control, where the user/operator of that machine was unaware that there even was a computer in there. Being a computer was not the point. Getting that one job done as part of some bigger mechanical/electrical system was the only point. The anti-lock brake system in your car is a good example. An embedded system is generally not reprogramable by the user. Why would he reprogram it? He doesn't even know he has a computer there.
With that definition in mind an embedded system could well be a huge old mainframe.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I would consider those "embedded" And I would agree that C++ is probably used (at least in part) in some of the devices you mention. But all the devices you mention constitute no more than a small fraction of the total number of embedded processors actually deployed each year - and it's not "my" definition of embedded - see en.wikipedia.org/wiki/Embedded_system.
Somehow, I don't think C++ finds much use in digital watches. Or in an MP3 players. Or in industrial controllers, routers, printers, refrigerators, microwave ovens, washing machines or calculators. Or (God forbid!) in cars, medical equipment, nuclear power plants or air traffic control systems.
Almost by definition (this is discussed on the wikipedia page) embedded processors - especially for high volume applications - are nearly always chosen to be "just big enough" to do the job required. If a tiny MCU can do it (using C) then it is selected over a larger MCU that could also do it (using C++) - even (and I know this from my own experience) if the saving is only a few cents per processor.
And if you are going to say that C++ requires no more resources than C, then please read
"When programming C++ in space- and runtime-sensitive environments like microcontrollers, extra care should be taken to avoid unwanted side effects of the C++ calling conventions like implied copy constructors that could be called upon function invocation etc. These things could easily add up into a considerable amount of time and program memory wasted. Thus, casual inspection of the generated assembler code (using the -S compiler option) seems to be warranted.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
heater said...
True but I don't care. If statistics of other peoples behaviour we so important to me then I should not be using a Propeller but a PIC or AVR. Heck I'd probably have spent the last month glued to the TV watching football.
Actually, I agree 100% It's just occasionally nice to check over the fence and how well "reality" is doing
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
"When programming C++ in space- and runtime-sensitive environments like microcontrollers, extra care should be taken to avoid unwanted side effects of the C++ calling conventions like implied copy constructors that could be called upon function invocation etc. These things could easily add up into a considerable amount of time and program memory wasted. Thus, casual inspection of the generated assembler code (using the -S compiler option) seems to be warranted.
I've read that many times having programmed AVR with GCC.
I still say that "C++ requires no more resources than C". Not only that I have proved it. I can send you the code examples if you don't believe.
I should point out the many warnings should be issued and "extra care" should be taken when using C:
Be aware that malloc does actually eat memory and makes your execution time unpredictable. (You won't spot that by examining your compiler output)
Be aware that declaring big arrays and structs on the stack may lead to unexpected failure.
Be aware that using floating point will seriously bloat and slow down your code.
Be aware that dangling pointers will lead to random failures.(return a pointer to a var on the stack anyone?)
etc etc.
For sure C++ gives you a lot more rope to hang yourself with but it does not require that you do so[noparse]:)[/noparse]
As I said the lack of those features you mention (new/delete, exceptions etc) due to the absence of libstdc++ save one from a lot of those C++ perils and is an advantage in this context.
I don't think those implied copy constructors mentioned above will even compile/link without new/delete.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
RossH: Maybe one of the nameless motor car manufacturers did use C for the acceleration/braking system or just maybe they used a windoze base and had it locked up when the brakes were applied???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
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've thought about what you propose - but the problem is that simply checking the bit on each instruction fetch slows down the LMM loop so much that it is not worthwhile. Maybe on the Prop II.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Attached is a discussion of the overheads of C++ vs C. It categorizes C++ language features as FREE, CHEAP or EXPENSIVE comparing the overheads of using them to C. The summary is:
Some comments on the dracblade on page three of this thread.
This comment of yours on page 1 In fact, given the severe size and complexity limitations of PASM, and the severe performance limitations of SPIN, I've come to think of LMM as the true "native" assembly language of the Prop
Hmm - maybe it is.
Hmm, does Hmm stand for Henning Memory Model?
Just to backtrack and refresh my brain which has been knocked around a bit after trying snowboarding for the first time (without a helmet on the first day, silly me), did we ever get catalina working on the dracblade?
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?
The dracblade driver code is fairly compact (cluso's is smaller again).
I'm pondering a 512k flat memory model using the external ram chip. Run your HMM/LMM emulation. Add in your extra pseudo pasm opcodes (I think you already have one or two of these, so adding a few more might not be so hard). Dump the entire 512k program from sd card to external ram (KyeDOS can handle this). Put the driver code from sd into hub so it can be transferred to a cog (this hub code can then be deleted, thus freeing up all the hub ram for other things, eg video buffer memory). The HMM/LMM interpreter cog then starts running the program from external ram.
(if there is enough space left over in the cog, add some cache space if you like)
So much of this is already done. I'm not familiar with all the internal workings of catalina, but would you need a new pseudo pasm op - a jump instruction that can handle anywhere within a 512k ram space with one long. What is that - 19 bits for the location to jump to, then you have the rest of the bits to say it is a jump.
I'm thinking of a hypothetical program that has a number of functions each of which has a local big array of, say, 10000 elements. So when compiled it becomes
data array
code
data array
code
...
This would be so much easier to write for the compiler if you have a large flat memory model.
Just random thoughts. If they don't make sense, I can just put it down to all the falls onto hard packed snow/ice *grin*. Thoughts would be most appreciated.
I found the "EXPENSIVE" assessment for templates to be suspect, in my experience working in C++, so I went to the section in the posted document on templates and found the following summary:
PDF document said...
Because template complexity can vary enormously, from a simple macro expansion with a couple of lines of code to a complex set of functions generating lots of code, the cost also varies. Templates can be FREE, CHEAP, or EXPENSIVE.
This I can believe -- a powerful tool can be used many ways with many consequences.
You have a lot of catching up to do. This forum has kept me up all nigh a couple of times. I can't keep up any more.
Looks like you had a good trip, great to see a real Catalina, a beautiful machine.
I wish I'd never mentioned the "Henning Memory Model" (HMM), I was not being so serious but it's been echoing around here since and Bill won't be happy about that. People already get confused enough over LMM vs XMM etc.
I'm sure Catalina would be very happy with any flat memory space out in external RAM. No new instructions required, just the PASM code to read write from the RAM. I'd better let Ross answer those questions though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ding-Batty: Yes that's what I though about templates as well. If I create a FIFO buffer, for example, with templates I don't have to write a different version for a char buffer, an int buffer, etc etc. I just write one templated function and instantiate what I want. I'm sure the generated code will be just as concise as all those different C versions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
Those great examples, that I have not heard before. Thanks for posting them!
I totally agree, the patent system is in terrible shape.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The highlight of that research was a book on the history of steam boiler explosions. Well "history" it was written a hundred years ago. Wish I could find it again. This sort of thing makes me really popular at parties[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I don't want to speak for Bill, but I don't think he would seriously want to impede the use of LMM by others - he simply (and rightly) asks to be credited as the first one to apply the idea to the Propeller.
I also don't think there are any grounds for LMM to be patentable. LMM is just a one instruction code overlay, and I don't think you could patent the use of code overlays - there is plenty of prior art in this area (and also some existing patents held by IBM - so in fact we may already be in trouble!). Of course, if anybody knows better then feel free to let us know.
As for the Arduino (or now Bill's ProDuino!) - I think this is great. It will really help Parallax in the hobbyist domain, where I think it may indeed have been losing some ground to platforms like that. It will also encourage someone to port GCC. However, C++ may be attractive to hobbyists, but in the embedded domain it is simply a non-starter. Of course, GCC can be used for just plain old C as well, so it would still be beneficial.
Ross.
EDIT: Should have read the rest of the thread before commenting. Bill has explained his purposes and intentions regarding LMM quite succintly!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 7/15/2010 11:01:58 PM GMT
Your comment below is basically where I take issue.
Credit is almost always in the fine print, at the bottom of an "About" box, etc., where exactly would you like the credit to be placed?
The request for one or two copies of any commercial product seems over the top.· What if GM wanted to use a prop as part of say an engine control device and they used a compiler that produces LMM code, would you like a pair of Corvettes?
I see LMM as being fundamental to using the prop in a lot of cases, and agree completely that the credit goes to you for formalizing the idea and getting it into the hands (and props) of the community.· I have no problem with calling it HMM as someone suggested.· I just think there needs to be a point where it is considered a fundamental way of coding for the prop that is freely available when used in the context of a prop chip.
BTW, I have no current plans to do anything with the prop, other than maybe the 1802 stuff, which won't need LMM anyway, so I don't have any hidden motivation. When I said...
"I don't mean this as being disrespectful to Bill, he has obviously made a lot of contributions to the prop community, but at this point I think he is holding it back."
I should have said something more like "...but at this point his controlling attitude towards LMM may be holding it back.
My goal here is to get the community to think about how a potential commercial user might look at the prop and some of the potential IP barriers to using it.· To me this one would be a pretty big red flag to the legal department.
C.W.
·
Although I don't consider LMM to be an overlay, more of a microcode execution mechanism [noparse]:)[/noparse] [noparse]:)[/noparse] [noparse]:)[/noparse]
I had quite a "WOW" moment when I came up with it; I'd been doing some indexing with self-modifying code, when it hit me - why not have a tight loop that modifies the instruction to be executed, based on the contents of the hub? Thus LMM was born...
The whole idea with LMM was to treat a cog as a microcode engine, and kernel routines as microcode extensions; implementing a classical register machine that happened to have a LOT of registers. FCACHE was an attempt to get most of the possible "microcode" speed back [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
I suspect you and I will never agree.
It is perfectly reasonable for me to ask for copies of compilers that generate LMM code, or other interesting LMM based applications.
Your Corvette engine controller argument is ludicrous. Your concerns and assumptions, in my opinion are unwarranted and baseless.
For your information, no matter how you try to frame it, I did not formalize the idea. How could I "formalize" something that did not exist?
I came up with it.
Perhaps someone would have come up with it a few months after I did. Perhaps no one would have come up with it for years. No one will ever know.
I did come up with it, and subsequently published to prevent submarine patents. I do ask for credit, as no matter how you try to phrase it, I did come up with it.
Had you come up with an enabling technology, and all you asked for was appropriate credit, I would have praised you, and gladly given credit in any project where I used your technique.
I guess we are different in one major respect. I like giving credit where it is due.
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 hereby award you TWO free copies of the Catalina C Compiler. You can download it (twice!) from catalina-c.sourceforge.net
You will find yourself suitably acknowledged in the Catalina Reference Manual. However, I draw the line at rewriting all the documenation to replace LMM with HMM!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
LOL!!!!
I saw the acknowledgement a long time ago, and appreciated it. I appreciate your efforts to support Morpheus just as much [noparse]:)[/noparse]
No need to re-write; I actually chose LMM as it was descriptive, and I did not feel a need to embed my name in the acronym.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 never said credit was not due, I was just put off when you jumped in when someone called LMM "hub pasm".
Not sure how my argument is ludicrous, you are the one that said "any", and if it is just for curiousity then why two items.
I'm not here to argue with you, as you have determined we will never agree on this matter.
C.W.
You came across as resenting my wanting credit, and I only jumped in about "hub pasm" as I did not want to confuse new users.
The two items is actually a good question. The reason is simple... many software products have a dongle, or a software lock. I change my computers often.
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Overlays were mentioned. My overlay technique/code has acknowledgements to the users who developed the reverse loop, etc. But what I wanted to say was that we were using overlays in 1974 but in fact the OS used overlays in the first code release way back in 1969. That was a Friden/Singer/ICL mini. Don't know about IBM - maybe they didn't know?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Why do you say so? C++ is fine on small embedded systems.
Perhaps you missed it but in the Zog thread Bill and I debated the use of C++ for small, memory limited, real-time embedded systems. There you will find example C++ code and the resulting compiler output which shows there is no downside to using C++.
I will not reproduce it the code here but it goes like this:
1) Imagne you want multiple instances of some functionality, a serial line protocol say, or a cyclic buffer, whatever.
2) In C you could cut and paste the code for one instance into another, renaming the funcs and vars so that it compiles. Then use both copies in your app. This is fast in execution but doubles the code space required.
3) Or in C you might get clever and have one copy of the code and multiple copies of the instance data using structs. This saves code space but now yo have to pass a pointer to every function so that it knows which instance you are working on at any moment.
4) Or you might use C++. Instantiate the required number of objects for you app satically. (not on the heap with new not on the stack). Here C++ takes care of thatinstance pointer for you.
Turns out that with GCC at least the generated code for 3) and 4) is almost exactly the same. That is C++ does neatly and automatically what you would do in C. The source code looks much nicer without all that pointer stuff.
In fact in all the examples I tried the C++ code came out a couple of bytes smaller.
On this discovery, which surprised me, I chose to use C++ in libzog and now find they have been doing it forever in Arduino land.
The point is to make use of C++ features that make your code easier to write and maintain and is generally prettier whilst staying away from it's features that make it memory hungry and slow.
Having worked on a number of embedded projects in the past that were using object oriented techniques in C I'm very glad this works so well in C++.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think you worry to much and you should get a new legal department.
If that department:
1) Understood programming
2) Had read all the code you and you colleagues write for the company
3) Knew every current relevant patent
Then they would probably never let you actually release anything for fear of being sued.
What we are talking about here is 4 lines of assembler basically. That's unlikely to be enforceable as a patent given all the prior art of overlays, self-modifying code etc etc going back to the dawn of computing.
As for copyright, I seriously doubt it has a case.
Reality is that Bill has no say in this at all. But he has done the Prop community a great service by publishing the idea which is now used by Catalina and ICC C compilers which may never have existed or been slower coming without it. I'm sure LMM is used in other places to, heck I even wrote my own small language compiler to use it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm not saying C++ can't be used. I'm not even saying it shouldn't be used. I'm saying it simply doesn't get used - at least not very much!
This has been discussed several times in several other threads. The statistics are simply irrefutable. C++ gained a small amount of traction in embedded work a few years ago (when it was all the rage in other domains) but it never made it anywhere near the top of the list, and has been on the decline ever since (I'm sorry, I can't quote the figures offhand - but I have quoted them in other threads, and they are easy enough to find if you look).
Actually, even the raw figures don't tell the full story since I know they include some companies that claim to use C++ when all they really do is use a C++ compiler but limit themselves to a subset of the language that is little more than plain old C anyway (I have worked for such a company). This is perfectly understandable - I think what you found in the Zog thread was that C++ compilers are often better at compiling simple C than C compilers - but this is just a reflection that there is little incentive for C compilers to strive for much more efficiency than they reached quite a few years ago, whereas C++ compilers absolutely continue to have to do so!
You also have to keep in mind that when people say "embedded" they often mean nothing more than a headless PC. Of course if you have a gigabyte of RAM, a terabyte of disk and a multicore gigahertz processor then you might consider writing your embedded application in C++. You can even run it on Windows or Unix and still call it embedded - but this isn't really the same as the type of embedded application for which a Propeller would be an appropriate choice.
There are also various technical reasons why C++ is not particularly suitable for embedded work, and these are explored in depth in many places. Two simple examples: you generally find it isn't a good idea to use things like exceptions or templates (which rules out the entire STL) in an embedded application.
I'm not against C++ - I have also developed "embedded" applications in C++ (of the "Unix" variety). And I have also thought for a while that there is room for a language that is as efficient as C but which removes some of the C "gotchas", adds some of the C++ "niceties" but omits the C++ "gotchas" (and C++ has more bizarre "gotchas" than C ever did!). But unfortunately "there just ain't no such animal" - and if there were it probably wouldn't get used anyway!
Given a choice between C and anything, most embedded companies still choose C. Why wouldn't they? - C is cheap, fast, does the job required, requires no training, is future proof, and runs on every microproessor/microcontroller they currently use or may ever choose to use. This combination is pretty hard for any other language to beat.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I think your definition of embedded is a more limited subset than what others (myself included) might define it as...
Most likely if you don't limit embedded to only mean tiny MCUs with extremely limited resources then you might find that C++ suddenly becomes the overwhelming giant elephant in the room.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
True but I don't care. If statistics of other peoples behaviour we so important to me then I should not be using a Propeller but a PIC or AVR. Heck I'd probably have spent the last month glued to the TV watching football.
No that's not what I found. What I found was that using C++ in a way that makes sense for a memory constrained system generates exactly the same code as using an object oriented approach in C.
So for example in C I might have multiple instances of some object defined by a struct and some functions. To use that object I write:
where "anInstancePointer" selects the data for the instance I want to work on.
In C++ I write:
Both those calls generate exactly the same code, barring difference in some immediate values.
This was a surprise even to me having used C for embedded systems for years and having seen how bloaty a C++ program can become on a PC.
Now there are many other C++ features one could use with no overhead over C. For example say I want cyclic buffers. In C I might write one for chars and one for ints etc. In C++ I could use templates to get those from the same source with no overhead. And so on. I'm not done with exploring this yet.
My conclusion is that embedded engineers have never really been learned how to use C++ efficiently. Of course if your code starts filling up with new/delete and string and the C++ standard library you are in trouble. It's not their fault, C++ is never presented in the context of small systems, check any beginners tutorial.
The Arduino guys learned this and use it very well it seems.
I agree exceptions are a disaster for embedded. Actually I don't like them anywhere.
The STL is obviously out. But then so is any huge library in any language if you don't have the space. In embedded work I want all my memory usage under my control. So most of STL is not relevant anyway.
Not sure template should be written off so easily. Using them to generate code operating on different types seems safe enough to me. I have to experiment with some simple use of templates.
You make a good point about portability of C++. Until C++ is available for every little chip its a risky proposition in that respect. But hey isn't GCC available for everything that's important any way?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Actually no I don't think mobile phones and PDA are embedded systems. Especially not nowadays. I've just order myself a Android based phone. 1GHz processor, 512M RAM, 2GB ROM 32GB SD card. High res display and programmable by me. That exceeds the spec of the PC I was using 5 years ago by 10 or more in all numbers. Perhaps there are still some "normal" phones around that I might call embedded systems.
Same applies to gaming systems nowadays.
Now my point is that "embedded system" is not defined by how big it is physically, how fast it's processor is, how much memory it's got etc etc.
No, where I come from an "embedded system" was some compute platform that performed whatever task, say machine control, where the user/operator of that machine was unaware that there even was a computer in there. Being a computer was not the point. Getting that one job done as part of some bigger mechanical/electrical system was the only point. The anti-lock brake system in your car is a good example. An embedded system is generally not reprogramable by the user. Why would he reprogram it? He doesn't even know he has a computer there.
With that definition in mind an embedded system could well be a huge old mainframe.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I would consider those "embedded" And I would agree that C++ is probably used (at least in part) in some of the devices you mention. But all the devices you mention constitute no more than a small fraction of the total number of embedded processors actually deployed each year - and it's not "my" definition of embedded - see en.wikipedia.org/wiki/Embedded_system.
Somehow, I don't think C++ finds much use in digital watches. Or in an MP3 players. Or in industrial controllers, routers, printers, refrigerators, microwave ovens, washing machines or calculators. Or (God forbid!) in cars, medical equipment, nuclear power plants or air traffic control systems.
Almost by definition (this is discussed on the wikipedia page) embedded processors - especially for high volume applications - are nearly always chosen to be "just big enough" to do the job required. If a tiny MCU can do it (using C) then it is selected over a larger MCU that could also do it (using C++) - even (and I know this from my own experience) if the saving is only a few cents per processor.
And if you are going to say that C++ requires no more resources than C, then please read
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Actually, I agree 100% It's just occasionally nice to check over the fence and how well "reality" is doing
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I've read that many times having programmed AVR with GCC.
I still say that "C++ requires no more resources than C". Not only that I have proved it. I can send you the code examples if you don't believe.
I should point out the many warnings should be issued and "extra care" should be taken when using C:
Be aware that malloc does actually eat memory and makes your execution time unpredictable. (You won't spot that by examining your compiler output)
Be aware that declaring big arrays and structs on the stack may lead to unexpected failure.
Be aware that using floating point will seriously bloat and slow down your code.
Be aware that dangling pointers will lead to random failures.(return a pointer to a var on the stack anyone?)
etc etc.
For sure C++ gives you a lot more rope to hang yourself with but it does not require that you do so[noparse]:)[/noparse]
As I said the lack of those features you mention (new/delete, exceptions etc) due to the absence of libstdc++ save one from a lot of those C++ perils and is an advantage in this context.
I don't think those implied copy constructors mentioned above will even compile/link without new/delete.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
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
Ok - we all know we're going to get there in the end, so let's just cut to the chase: burks.bton.ac.uk/burks/language/shoot.htm
Ross.
P.S. Actually, I'm slightly perturbed by how much this icon looks like me ->
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I've thought about what you propose - but the problem is that simply checking the bit on each instruction fetch slows down the LMM loop so much that it is not worthwhile. Maybe on the Prop II.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Humanoido tells us there are now 157 ways to make holes in feet using a Propeller now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
encapsulation/classes - FREE
namespaces - FREE
inlining - FREE
operator overloading - FREE
constructors/destructors - FREE
references - FREE
virtual functions - CHEAP
templates - EXPENSIVE
STL (Standard Template Library) – EXPENSIVE
RTTI – EXPENSIVE
exceptions - EXPENSIVE
Which is pretty much what we have worked out already.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I've been on holidays and out of Forum contact for over a week. The withdrawal shakes have been getting bad...
Just driven 800km today and got back late tonight to find this interesting thread.
As an aside, we drove past this place www.murrayriver.com.au/lake-boga/ where they have a nice catalina.
Some comments on the dracblade on page three of this thread.
This comment of yours on page 1
In fact, given the severe size and complexity limitations of PASM, and the severe performance limitations of SPIN, I've come to think of LMM as the true "native" assembly language of the Prop
Hmm - maybe it is.
Hmm, does Hmm stand for Henning Memory Model?
Just to backtrack and refresh my brain which has been knocked around a bit after trying snowboarding for the first time (without a helmet on the first day, silly me), did we ever get catalina working on the dracblade?
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?
The dracblade driver code is fairly compact (cluso's is smaller again).
I'm pondering a 512k flat memory model using the external ram chip. Run your HMM/LMM emulation. Add in your extra pseudo pasm opcodes (I think you already have one or two of these, so adding a few more might not be so hard). Dump the entire 512k program from sd card to external ram (KyeDOS can handle this). Put the driver code from sd into hub so it can be transferred to a cog (this hub code can then be deleted, thus freeing up all the hub ram for other things, eg video buffer memory). The HMM/LMM interpreter cog then starts running the program from external ram.
(if there is enough space left over in the cog, add some cache space if you like)
So much of this is already done. I'm not familiar with all the internal workings of catalina, but would you need a new pseudo pasm op - a jump instruction that can handle anywhere within a 512k ram space with one long. What is that - 19 bits for the location to jump to, then you have the rest of the bits to say it is a jump.
I'm thinking of a hypothetical program that has a number of functions each of which has a local big array of, say, 10000 elements. So when compiled it becomes
data array
code
data array
code
...
This would be so much easier to write for the compiler if you have a large flat memory model.
Just random thoughts. If they don't make sense, I can just put it down to all the falls onto hard packed snow/ice *grin*. Thoughts would be most appreciated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
You have a lot of catching up to do. This forum has kept me up all nigh a couple of times. I can't keep up any more.
Looks like you had a good trip, great to see a real Catalina, a beautiful machine.
I wish I'd never mentioned the "Henning Memory Model" (HMM), I was not being so serious but it's been echoing around here since and Bill won't be happy about that. People already get confused enough over LMM vs XMM etc.
I'm sure Catalina would be very happy with any flat memory space out in external RAM. No new instructions required, just the PASM code to read write from the RAM. I'd better let Ross answer those questions though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.