CardboardGuru said...
>So the d-field contains the source data, and the s-field contains the destination. i.,e. The WRxxxx instructions use the bitfields in an opposite meaning from every other instruction. And that's the reason why the assembler does too.
<2cents>For WR* and RD*, what helps me is to forget about dest/source and instead to think cog/hub (i.e. the first operand is the cog address, the second is the hub pointer; the choice of RD or WR determines which way the data goes).</2cents>
Off-Topic
With two-address instructions one of them has to determine the address a result shall be copied to, if any. This is - very systematically - ALWAYS the left hand operand, whilst the right hand operand can ALWAYS be used in immediate mode.
This can easily be memorized by the SPIN/C-style compound assignment operations
+= etc.
The exceptions are
RD..
WR..
WAITP..
LOCKSET
LOCKCLR
which primarily have side-effects.
BTW: You will be surprised what the (senseless) R-bit is used for with these instructions ....
Luckily LOCK... have one parameter only (and few use it). The parameters of RD../WR.. can be easily memorized (And they have nothing to do with the fact what kind of data transfer is going on).
But I doubt that many persons are always confident what's the MASK and what's the VALUE with WAITP...
I guess I'm a little confused about whether this thread is mostly a rant about frustrations with Spin and the IDE and odd bits about the instruction set, etc. or a critique of the Spin language and IDE and the choice to use a custom language rather than a standard one, etc.
The Propeller is a "done deal" in most ways. The instruction set is fixed and will only be extended in a few limited ways in version 2. Spin is essentially fixed and very tightly constrained by the available cog memory, so will not change significantly in version 2.
Others, like ImageCraft, will produce compilers for other languages at a price. Other interpreters, like Forth, may be forthcoming, but again there's a big difference between hobby / academic tools and tools where the huge time involved is paid for by charging for them. Several people have started projects to build on open-source development tools. Maybe they'll get done and maybe not. It will be nice to have other tools, but I'm not going to "hold my breath" and, for commercial use, ongoing support is always problematic. When the community gets large enough, that can work, but the Propeller community is not very large.
deSilva,
Ideals are nice and an orthogonal instruction set is nice. Building things is sometimes messy. That's the difference between mathematics and engineering. The latter is informed by the former. Engineering becomes crude without the beauty and power of mathematics. Sometimes though you have to make ugly choices because perhaps the cost of doing something "properly" is too high. There are always hidden costs associated with these choices, but often they end up being less than the incremental cost of the "proper" choice. This is typically true in the embedded processor business. Witness the "ugliness" of the hugely successful PIC microprocessor line and the SX is not much better. The instruction sets and architecture are irregular with many special cases and "gotcha"s. For simple projects you can use a medium level language like C which insulates you from many of the quirks, but whenever you try to use the cheapest processor that will do the job, you have to do a lot of it in assembly and you just have to know how the part works. The Motorola 6800 based embedded processors have cleaner instruction sets, but I don't see them used much.
Post Edited (Mike Green) : 12/2/2007 6:58:08 PM GMT
Mike Green said...
...but whenever you try to use the cheapest processor that will do the job, you have to do a lot of it in assembly and you just have to know how the part works
But we are NOT using the cheapest processor
WRT to your other remarks I am definitely on your side
> I guess I'm a little confused about whether this thread is mostly a rant about frustrations with Spin and the IDE and odd bits
> about the instruction set, etc. or a critique of the Spin language and IDE and the choice to use a custom language rather
> than a standard one, etc.
Good question!
For clarification, the Propeller needs a different language or at least some add ons to an existing (and maybe stripped down) language.
I'm complaining about the way it was done. There would have been much more elegant solutions (I could show you some with the assembler too).
Yes, it's -to some degree- frustating to work with SPIN/ASM/Prop-IDE. IMHO!
Thankfully, the frustration level isn't high enough not to be compensated by the nice chip and the results you (or others and I) can get with.
If I would have the time, I'd like to design a new streamlined language that can do what SPIN can do and also use the interpreter.
Thanks god, the interpreter isn't available.
> The Propeller is a "done deal" in most ways.
First, it is some square-millimeters of silicon. Some clever silicon!
SPIN is only to some extend cast in silicon. The rest is in your PC. Can't imagine that the interpreter is so specialized that it isn't possible to rewrite the compiler and redesign SPIN. Maybe the next gen is called NIPS?
> but the Propeller community is not very large.
Maybe because of SPIN? ))
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
Nick,
It's always nice to be able to vent one's frustrations and say what should have been or what could have been. The reality is that Parallax has committed to Spin as it exists, that they do not have the resources to do anything other than support the existing Spin compiler and IDE as it exists or with very minor changes to the IDE only. They do give it away for free and provide excellent free support and you get much more than you paid for it. Lastly, the resources available to them for this sort of thing are not likely to change in the future. They have enough experience in this business to know how their resources need to be allocated.
If you don't like that, then you can go use some other microcontroller with the tools that are available for it or you can devote the substantial time and effort to do something else yourself or convince like minded people to help out. That doesn't work if you don't yourself commit extensive time and effort to the task. Third choice is to pay someone else for the privilege of doing the hard work like ImageCraft. Their prices are not unreasonable for what they provide, but they're out of reach for many hobbyists or for people who are interested in the Propeller, but not committed to its use.
deSilva,
I know we're not using the cheapest processor, but the Propeller is relatively cheap for its functionality and it is ground-breaking in many ways. It "pushes the envelope" in terms of its design and I can see clearly where some of its "non-orthogonality" might have its roots in the chip layout or chip area concerns, for example, the WR.... instructions' use of the destination field for the COG address and the source field for the HUB address rather than keeping the notion of "source" and "destination" pure.
Jeff and I designed Spin to be a simple, easy to learn, high-level language that lets you take care of business without getting·hung up on type constraints. It's simple, we think, and if you aren't overly biased by past experience, it should be quick to pick up. It's meant to·get out of your way fast,·so you can do what you want.·It does help if you have a good base understanding (and love)·of word sizes and 2-complement arithmetic.·Spin is rather simplistic and·won't second-guess your intent.
As an assembly programmer, it was always frustrating to me when a high-level language cut me off from the base phenomena of binary math and logical operations. Spin doesn't do that, but it also doesn't provide automatic support for lots of types, either. You've got bits, ranges of bits, bytes, byte z-strings, words, longs, and compiler awareness of floats·- that's it. Everything beyond these is built by you. But we like that, because you can do it exactly the way you want, without unwanted/unfixable boundary behaviors. It's all up to you.
Also, I should say that high-performance code is best written in assembly. At the top level, Spin can be used to·tie things·together very nicely, as the bandwidth is always lowest at the top. So,·Spin's relatively slow interpretation is not a show-stopper - at least, I've always been able to make it work quite well by complementing it with assembly where needed.
Here is how you might consider the bandwidth/complexity order:
Low-complexity / high-bandwidth
COG CTRs / COG Video - simplest, highest-speed pin operations
COG Assembly Language - high·speed computing and pin operations
Spin - lowest speed, but easiest to code complex operations
High-complexity / low-bandwidth
I know that not everybody's going to like Spin, but it is what Jeff and I thought was the very best thing to do - simple, terse, readable, scoped, and not overly typed.
To me, Spin's biggest shortcoming is lack of indirect calls and mixed data structures. This will get addressed in the future.
And consider this: for a 496-long SRAM cost, you could have your own high-level language interpreter doing whatever is better for you. It just takes time to make one. The biggest thing about something like this is not HOW to code it, but deciding WHAT it's going to do.
Please feel free to continue your critiques. I just wanted to interject some info about our design intent here.
Fred Hawkins said...
Chip, as long as you're here, how about·some discursive prose on negx, sumc, sumnc, & andn?
NEGx lets you move a source,·multiplied by +/-1,·into a destination register, based on a flag.
SUMx lets you·accumulate a source,·multiplied by +/-1, into a destination regsiter, based on a flag.
These kinds of operation are especially useful when doing sin/cos accumulation for Goertzel algorithms, DFTs, etc, when you're dealing with 1-bit sigma-delta samples.
Thanks for your comments!
I never complained about the lack of missing data-types. I think what SPIN offers here is just enough, and I can well live with that. It is quite near to the processor and good enough for many applications. I am aware, that it's running on a µC and I'd never expect SPIN to do things C++ could do. Data-structure can be simulated with some techniques and some diszipline. Not my point.
I'm not asking for a complex language, just for a straight language.
I'm also not complaining about the speed of SPIN. Your decision to let it run on a P-machine was right (in my eyes). It saves space.
I'm also not complaining about the propeller as a chip. Not the lack of ints, stack etc. It is an interesting approach and fun to work with.
Maybe you change your attitude about not publishing the P-code (or at least the P-opcodes) and about how to bootstrap the interpreter? That would enable interesting projects of the community.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
Comments
edit: This distinction is not my invention but lifted from this page: http://www.zetetics.com/bj/papers/moving1.htm
Post Edited (Fred Hawkins) : 12/2/2007 4:39:24 PM GMT
<2cents>For WR* and RD*, what helps me is to forget about dest/source and instead to think cog/hub (i.e. the first operand is the cog address, the second is the hub pointer; the choice of RD or WR determines which way the data goes).</2cents>
With two-address instructions one of them has to determine the address a result shall be copied to, if any. This is - very systematically - ALWAYS the left hand operand, whilst the right hand operand can ALWAYS be used in immediate mode.
This can easily be memorized by the SPIN/C-style compound assignment operations
+= etc.
The exceptions are
RD..
WR..
WAITP..
LOCKSET
LOCKCLR
which primarily have side-effects.
BTW: You will be surprised what the (senseless) R-bit is used for with these instructions ....
Luckily LOCK... have one parameter only (and few use it). The parameters of RD../WR.. can be easily memorized (And they have nothing to do with the fact what kind of data transfer is going on).
But I doubt that many persons are always confident what's the MASK and what's the VALUE with WAITP...
The Propeller is a "done deal" in most ways. The instruction set is fixed and will only be extended in a few limited ways in version 2. Spin is essentially fixed and very tightly constrained by the available cog memory, so will not change significantly in version 2.
Others, like ImageCraft, will produce compilers for other languages at a price. Other interpreters, like Forth, may be forthcoming, but again there's a big difference between hobby / academic tools and tools where the huge time involved is paid for by charging for them. Several people have started projects to build on open-source development tools. Maybe they'll get done and maybe not. It will be nice to have other tools, but I'm not going to "hold my breath" and, for commercial use, ongoing support is always problematic. When the community gets large enough, that can work, but the Propeller community is not very large.
deSilva,
Ideals are nice and an orthogonal instruction set is nice. Building things is sometimes messy. That's the difference between mathematics and engineering. The latter is informed by the former. Engineering becomes crude without the beauty and power of mathematics. Sometimes though you have to make ugly choices because perhaps the cost of doing something "properly" is too high. There are always hidden costs associated with these choices, but often they end up being less than the incremental cost of the "proper" choice. This is typically true in the embedded processor business. Witness the "ugliness" of the hugely successful PIC microprocessor line and the SX is not much better. The instruction sets and architecture are irregular with many special cases and "gotcha"s. For simple projects you can use a medium level language like C which insulates you from many of the quirks, but whenever you try to use the cheapest processor that will do the job, you have to do a lot of it in assembly and you just have to know how the part works. The Motorola 6800 based embedded processors have cleaner instruction sets, but I don't see them used much.
Post Edited (Mike Green) : 12/2/2007 6:58:08 PM GMT
WRT to your other remarks I am definitely on your side
> about the instruction set, etc. or a critique of the Spin language and IDE and the choice to use a custom language rather
> than a standard one, etc.
Good question!
For clarification, the Propeller needs a different language or at least some add ons to an existing (and maybe stripped down) language.
I'm complaining about the way it was done. There would have been much more elegant solutions (I could show you some with the assembler too).
Yes, it's -to some degree- frustating to work with SPIN/ASM/Prop-IDE. IMHO!
Thankfully, the frustration level isn't high enough not to be compensated by the nice chip and the results you (or others and I) can get with.
If I would have the time, I'd like to design a new streamlined language that can do what SPIN can do and also use the interpreter.
Thanks god, the interpreter isn't available.
> The Propeller is a "done deal" in most ways.
First, it is some square-millimeters of silicon. Some clever silicon!
SPIN is only to some extend cast in silicon. The rest is in your PC. Can't imagine that the interpreter is so specialized that it isn't possible to rewrite the compiler and redesign SPIN. Maybe the next gen is called NIPS?
> but the Propeller community is not very large.
Maybe because of SPIN?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
It's always nice to be able to vent one's frustrations and say what should have been or what could have been. The reality is that Parallax has committed to Spin as it exists, that they do not have the resources to do anything other than support the existing Spin compiler and IDE as it exists or with very minor changes to the IDE only. They do give it away for free and provide excellent free support and you get much more than you paid for it. Lastly, the resources available to them for this sort of thing are not likely to change in the future. They have enough experience in this business to know how their resources need to be allocated.
If you don't like that, then you can go use some other microcontroller with the tools that are available for it or you can devote the substantial time and effort to do something else yourself or convince like minded people to help out. That doesn't work if you don't yourself commit extensive time and effort to the task. Third choice is to pay someone else for the privilege of doing the hard work like ImageCraft. Their prices are not unreasonable for what they provide, but they're out of reach for many hobbyists or for people who are interested in the Propeller, but not committed to its use.
I know we're not using the cheapest processor, but the Propeller is relatively cheap for its functionality and it is ground-breaking in many ways. It "pushes the envelope" in terms of its design and I can see clearly where some of its "non-orthogonality" might have its roots in the chip layout or chip area concerns, for example, the WR.... instructions' use of the destination field for the COG address and the source field for the HUB address rather than keeping the notion of "source" and "destination" pure.
As an assembly programmer, it was always frustrating to me when a high-level language cut me off from the base phenomena of binary math and logical operations. Spin doesn't do that, but it also doesn't provide automatic support for lots of types, either. You've got bits, ranges of bits, bytes, byte z-strings, words, longs, and compiler awareness of floats·- that's it. Everything beyond these is built by you. But we like that, because you can do it exactly the way you want, without unwanted/unfixable boundary behaviors. It's all up to you.
Also, I should say that high-performance code is best written in assembly. At the top level, Spin can be used to·tie things·together very nicely, as the bandwidth is always lowest at the top. So,·Spin's relatively slow interpretation is not a show-stopper - at least, I've always been able to make it work quite well by complementing it with assembly where needed.
Here is how you might consider the bandwidth/complexity order:
Low-complexity / high-bandwidth
COG CTRs / COG Video - simplest, highest-speed pin operations
COG Assembly Language - high·speed computing and pin operations
Spin - lowest speed, but easiest to code complex operations
High-complexity / low-bandwidth
I know that not everybody's going to like Spin, but it is what Jeff and I thought was the very best thing to do - simple, terse, readable, scoped, and not overly typed.
To me, Spin's biggest shortcoming is lack of indirect calls and mixed data structures. This will get addressed in the future.
And consider this: for a 496-long SRAM cost, you could have your own high-level language interpreter doing whatever is better for you. It just takes time to make one. The biggest thing about something like this is not HOW to code it, but deciding WHAT it's going to do.
Please feel free to continue your critiques. I just wanted to interject some info about our design intent here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
I believe SUMx and NEGx are used in signal processing, an area that I know little about.
Say you have a mask for output pins:
CON DEBUG_LED = %00000000_00000000_00000000_00000001
Then
OR OUTA,#DEBUG_LED
will set the pin and
ANDN OUTA,#DEBUG_LED
will clear it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
SUMx lets you·accumulate a source,·multiplied by +/-1, into a destination regsiter, based on a flag.
These kinds of operation are especially useful when doing sin/cos accumulation for Goertzel algorithms, DFTs, etc, when you're dealing with 1-bit sigma-delta samples.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Thanks for your comments!
I never complained about the lack of missing data-types. I think what SPIN offers here is just enough, and I can well live with that. It is quite near to the processor and good enough for many applications. I am aware, that it's running on a µC and I'd never expect SPIN to do things C++ could do. Data-structure can be simulated with some techniques and some diszipline. Not my point.
I'm not asking for a complex language, just for a straight language.
I'm also not complaining about the speed of SPIN. Your decision to let it run on a P-machine was right (in my eyes). It saves space.
I'm also not complaining about the propeller as a chip. Not the lack of ints, stack etc. It is an interesting approach and fun to work with.
Maybe you change your attitude about not publishing the P-code (or at least the P-opcodes) and about how to bootstrap the interpreter? That would enable interesting projects of the community.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO