Re Floating point: Having to use another cog is quite expensive since cog-to-cog communication has to be via the hub. Also, there is the additional overhead of having to set up the command (and its parameters) in the client cog and then decoding them in the server cog (if your server cog implements more than just one function). Then of course you have to do the same back the other way to pass the result. The cost of invoking a function implemented in another cog can easily double or quadruple the cost of implementing the same function locally. This was a major early design decision in Catalina - i.e. keep everything possible in the kernel cog - and the resulting benefit to things like floating point performance is simply massive.
Re Structures: Do you have a program that disassembles compiled spin binaries into bytecodes? That would be very useful here to see just how many byte codes are generated. If my understanding of SPIN byte codes is correct, Calculating 'pstruct + istruct + x' should take around 8 such byte codes or operands - each of which requires a fetch from hub RAM. However, there is one optimization that you could do immediately - some of those additions don't need to be done at run time. For instance the offset of the field x (i.e. istruct.x) within type Test2 is constant. Keeping track of all field offsets would save you having to recalculate 'istruct +x' on each access - since you actually know where x is within the structure.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
BST produces a very detailed compiler listing.· Here's the output for the first line of CopyStruct.
16 byte[noparse][[/noparse]pstruct + istruct + x] := byte[noparse][[/noparse]@gstruct + istruct + x]
Addr : 0021: 43 : Variable Operation Global Offset - 0 Address
Addr : 0022: 35 : Constant 1 $00000000
Addr : 0023: EC : Math Op +
Addr : 0024: 35 : Constant 1 $00000000
Addr : 0025: EC : Math Op +
Addr : 0026: 80 : Memory Op Byte POP Address READ
Addr : 0027: 64 : Variable Operation Local Offset - 1 Read
Addr : 0028: 35 : Constant 1 $00000000
Addr : 0029: EC : Math Op +
Addr : 002A: 35 : Constant 1 $00000000
Addr : 002B: EC : Math Op +
Addr : 002C: 81 : Memory Op Byte POP Address WRITE
This is obviously not very efficient.· Clearly we don't need to add zero offsets, but it gives you an idea of the operations involved.· I did set the option in BST to fold constants, but it didn't do it for this case.
It's not supprising we disagree. However, for a start the newbie can use the C style syntax. If they want to advance to full C then hey, they get to use Catalina or ICC. It does give them a start with the syntax. While I think the forced indentation of spin is a good idea, it does upset those already used to coding in say C. Some of those already have bad habits and that is not good, but it is a valid argument.
It is such a shame we have all these languages which are similar, yet so different, at the most basic level. I mean Basic, C, VB, Pascal to name a few. Spin is just another.
Anyway, that's not progressing this thread and there are exciting ideas being posted here. These discussions are really proposing ideas to take the prop to the next level.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Ah thanks - I forgot about using BST! That byte code is pretty bad - SPIN takes 12 8 instructions to do what PASM can do in 3 (assuming the structure is a local variable). And it takes the same amount almost 2/3 of the RAM space to do it. So much for byte coded solutions being significantly smaller in size.
The "zero offsets" thing only applies to the first field element - if you had chosen another field than 'istruct.x', or the structure was arranged differently, then the offsets being added would not be all zeroes. The "folding constants" option might be able to achieve the optimization I mentioned earlier, bringing the result down from 12 to 8 8 to 6.
Ross.
@Cluso,
So your response to the proliferation of unnecessary languages is to introduce another one?
EDIT: Oops! I keep mis-counting the byte codes! To clarify, the LMM PASM instructions I wanted to compare the SPIN byte code against was a simple fetch from a local structure and a save to a local variable, which in LMM PASM is something like:
mov RI, FP ' get frame pointer
add RI, #n ' point to field in structure
rdlong Rx, RI ' save in cog register
I think this takes 8 byte codes and operands. If anyone thinks just leaving the result in a register is somwhow cheating, it isn't - LCC puts local variables in registers wherever possible, so most simple local variables (like loop counters) end up assigned to cog registers. Local structures, however, always exist in the frame, and Dave's actual C code (and sequence of byte codes) also saves the result back into a structure, so a more correct comparison would be something like:
mov RI, FP ' get frame pointer
add RI, #n ' point to field in structure
rdlong Rx, RI ' save in cog register
jmp #LODA ' get address ...
long @Q ' ... from Q
add RI, #m ' point to field in struct
wrlong Rx, RI ' save result in struct
This is what takes 12 SPIN byte codes and operands. However, this is not really a true comparison either, because treating these individually doesn't allow LCC To make the many trivial code optimizations (such as re-using common subexpressions that occur on multiple lines rather than recalculating them). These optimizations are simply not possible in SPIN byte codes (no local storage!) To see this, you might expect Catalina to take 21 instruction longs to execute the following 3 lines of C (taken from Dave's program):
[noparse][[/noparse]quote]
pstruct->istruct.x = gstruct.istruct.x;
pstruct->istruct.y = gstruct.istruct.y;
pstruct->istruct.z = gstruct.istruct.z;
However, the actual generated code is only 15 instruction longs. Even if we assume the SPIN compiler can do constant folding, the same 3 lines of C will take 24 bytes of codes and operands.
This is a good example of how LMM PASM can be expected to approach 2 times byte code size, but is typically much more than twice as fast.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
You'll have to forgive me since I have only progressed to 'toddler' in terms of my experience with Spin. My experience began with Pbasic in '08'. What is the value of understanding 'C' to people like me?
@lardom, Pbasic and Spin are only used with Parallax processors.· You cannot run Pbasic or Spin programs on any other processors.· The value of C is that it is a more generic and powerful language.· Almost any processor will have a C compiler.· This makes it possible to port C code from one processor to another.
@Ross, there is certainly value in using C versus Spin.· It has the advantages I mentioned above as well as being higher speed.· The only disadvantge is in cases where a Spin program will fit in 32K of RAM, but the C program won't.· In that case, maybe heater's approach to C would work.· It would be nice to have have a few benchmarks that compare speed and size for the various language options.
I have attached the first draft of a document that defines mnemonics for the Spin bytecodes.· I haven't added the unary opcodes that use the "effect" mode of RAM access.· I'll add those later.· For the most part I use the Spin/PASM opcode name if one exists.· Some other opcodes use fairly long names, such as "framenoret", which I plan on changing to something shorter.· In the case of framenoret, I'll probably call it frame or frm, and call the other frame instruction that supports a return value framer or frmr.
I plan on referring to the Spin assembly language as SASM.· I also thought about using SPASM, which fairly accurately describes my reactions as I dig deeper in Spin bytecodes.· My only concern about using SPASM is that it is a language that I recall from the early·70's.· I don't know if anyone programs in SPASM these days.
There are many opcodes for accessing hub RAM.· I hope my naming techique is straigh-forward enough.· Let me know if it seems confusing.
Dave
Edit: BTW, I have a SASM assembler working that can handle simple programs.· I was able to·assemble a "Hello World" program that runs under spinix.· I need to add DAT support to the assembler to make it really useful.· The assembler is currently 650 lines of C code, which includes a 200-line opcode table.· My plan is to convert the assembler to Spin after I add DAT support.
Post Edited (Dave Hein) : 7/22/2010 6:27:12 PM GMT
SPIN is a great language to learn. But as Dave points out, the most significant reason for also learning a bit about C (even if you choose not to use it) is that you will just keep meeting it again and again - because it is available on every processor ever devised (usually for free), and because so much existing software is written in it. The other reason is that it is probably the closest thing we have to a universal language. By that I mean a platform independent language that can implement any type of algorithm with equal felicity - or (as some people claim) with equal obscurity
@Dave,
I acknowledge the code size of LMM C prgrams compared to SPIN will remain a problem (just not as big a one as many people seem to think!) and that there is room for alternative implementations of C.
By the way, you are missing a great opportunity here - obviously the correct name for a SPIN-based Assembly language designed to rival PASM is ... SPAM!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Just read your byte code document. Very neat and logical.
Even though I prefer to program in C, every time I look at SPIN I am simply amazed at just how much functionality Chip manages to squeeze into a single cog! There has to be a way to exploit this effectively for use by more mainstream languages - my feeling is that it is the current emphasis on trying to use it as a vehicle for C is where we are going wrong - it would instead make a better vehicle for "higher level" stack and procedural based languages than the C family (C, C++, C# etc). A few years ago you probably would have said it was ideal platform for implementing languages like Pascal or Modula. In my day (gosh I feel old!) Pascal was the standard "first" language taught by most universities. I wonder what it is these days?
RossH, I'm not sure I understand your idea about how it might be better to have the Pascal or Modula languages targeted at Sin byte codes rather than C/c++.
I'm no language or compiler expert but I make the observation that C and Pascal have much the same data types and much the same control structures. Much the same ideas about functions and parameters etc. In fact as far as I can tell they are pretty much equivalent. As the language gurus say they are both "imperative" or "procedural" programming languages.
A different syntax, sure. Some semantic differences that make it a bit harder to hang you yourself in Pascal. I'm guessing that the code they generate could be quite similar.
So, I don't see why Pascal would be a better source language for Spin byte codes than C.
Perhaps you could elaborate.
In my day at university we had ALGOL (Gosh I am old) the mother of all such languages.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm not really suggesting Pascal, but I can't think of a better alternative yet. However, while I try and come up with one, I'll try and explain my reasoning a bit more ...
It's partly a matter of expectation. C is a "bit twiddling" language (as evidenced by the inclusion of things like bit fields, bitwise operators, different integer sizes, the deliberate "confusion" between arrays and pointers, pointer arithmetic, the ability to get the address of local variables etc). This leads people to expect to be able to operate at about the same low level - and achieve the same speed - as assembly language. But but this is not really practical in a language implemented using SPIN byte codes. This is why we mostly implement our drivers for the Propeller in PASM and not SPIN (excepting for the relatively slow serial drivers such as SPI and I2C). For example, I'm not aware of any video drivers - even a simple one - written in SPIN (mind you, I'm not aware of any written in C either!).
However, none of these features are present in Pascal, so people don't expect to be able to use Pascal to do such things. If Pascal executed at speeds comparable to SPIN, Pascal programmers (assuming there still are such people) would be perfectly happy. Nobody expects Pascal programs to be blindingly fast - Pascal has a long history of being implemented using a simple "pcode" interpreters, quite similar to the SPIN interpreter.
Pascal found an ideal niche as a teaching language, partly because it was "type safe" - this led to compilers that could generate better diagnostic messages to help programming newcomers identify potential programming problems more easily. Also, Pascal is also a "small" language - much like SPIN - with very simple libraries - this makes a complete and standardized implementation relatively easy.
As I say, I'm not actually suggesting Pascal, but I think there could definitely be advantages to using SPIN byte codes to implement languages other than just SPIN (for which it is obviously very suitable) or C (for which it is not particularly suitable). There's a whole spectrum of languages out there for which SPIN byte codes might be more suitable - there surely must be other languages out there with the right combination of ease-of-use (which Pascal and SPIN both have, but C definitely does not) and low-level features (which SPIN and C both have, but Pascal does not) and speed (which C has, but SPIN and Pascal do not).
Of course, part of the problem is that we're all making our own assumptions about which combination of these factors would suit Parallax best.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Ross, SPAM sounds good.· I mean the name, not the food product.· Or is it a by-product? Or is it even food?· Heater, I liked your reference to the Vikings.· I had to watch the Monty Python skit on YouTube.· It's hilarious.· Speaking of hilarious, the History of C was very amusing.· Of course, I had to read the History of Microcomputers and the History of Basic.· The Star Trek references were priceless.· I loved playing that game.
Even though SPAM is a good name I'm still thinking of other candidates.· SPASM was the Stanford single pass assembler that ran on the IBM 360.· I realized that SASM is an x86 assembler.· I'm now leaning toward the name SPASE (prounced like space).· I would be interested in any other suggestions for a name.
I've never programmed in Pascal, but I recall several programmers at my work in 1988 preferred it over C.· They felt that C didn't enforce enough structure to make it a reliable programming language like Pascal.· It was too easy to mess up things with a bad pointer in C.· Sounds like the History of C website.
I added support for defining a data area in SPAM/SASM/SPASM/SPASE.· I actually just added the three pseudo-ops byte, word and long, which insert 1, 2 or 4 bytes of data.· They can be added anywhere in the code.· There's really no reason to confine the DAT area to the beginning of the object like Spin does.· Of course, even Spin will insert STRING data within the body of the object.
I did a quick conversion from C to Spin just to see how large the code is.· The Spin version of the assembler is about 10KBytes.· That's without any buffers, but I shouldn't have any problems fitting it into spinix.
Pascal has the advantage of relatively strong data typing. There have been extended versions of Pascal for the Palm running on the Palm for both a 68xxx processor and the ARM Thumb processor. Much of the Palm Pascal compiler (particularly for the ARM) was written in Pascal although the earlier parts of it were written in C because that was available first. At one time, I did a native multipass Pascal compiler for both an 8080-class processor and a Z80, used to write a large word processor for the same processors. It doesn't take much in the way of extensions to interface with all sorts of hardware and low-level system calls.
Thank you. Old enough to know that you are totally wrong[noparse]:)[/noparse]
I have to pull your statements apart vigorously:
RoosH said...
"...However, none of these features are present in Pascal,"
C is a bit twiddleing languge for sure but I'm also sure you will find that anything you can do in C you can do in Pascal. It may lack the language features to express some things directly and cause you to do it in a round about way but I don't think there is a great loss in performance as a result.
See links below.
RoosH said...
If Pascal executed at speeds comparable to SPIN...
A lot of pascal programmers would be mightily upset.
RoosH said...
...Pascal programmers (assuming there still are such people) would be perfectly happy.
I think there is more Pascal programming going on than you imagine. Free Pascal is a thriving project.
Did I mention I am now getting to grips with a large body of Pascal code that absolutely needs speed. It's a simulation system. It needs to be fast.
You should try the Free Pascal compiler, it's blinding fast and it is written in Pascal.
Oh yes, and BradC has written BSTC in Pascal. That's pretty snappy. (Which by the way probably does a lot of bit twiddling what with having to build instruction bit fields and such.
RoosH said...
Nobody expects Pascal programs to be blindingly fast - Pascal has a long history of being implemented using a simple "pcode" interpreters, quite similar to the SPIN interpreter.
Well except nearly thirty years ago Borland introduced Turbo Pascal which compiled to native code and was pretty "turbo". I think everybody has expected Pascal to have C like speed ever since. I bet there have never been many real programs created with a pcode system.
RoosH said...
Pascal is also a "small" language - much like SPIN - with very simple libraries
Actually I would say "Pascal is a very small language - much like C"
I think we had a similar debate going on about C vs C++. In my mind "language" means language as defined by it's syntax and semantics. In that respect C and Pascal are about neck and neck. Whilst ADA, for example, is enormous. "language" does not include the libraries. Yes I know libs get standardized along with the language but I choose to ignore that.
For sure C has a lot stuff in it's libs and Pascal has a lot less. That is not the fault of the language as such. Perhaps if Pascal had become the most commonly used language decades ago it would now have evolved a similarly comprehensive set of libraries.
heater said...
... anything you can do in C you can do in Pascal.
In the sense that both languages are general purpose languages, I suppose that's true. But I also know I wouldn't choose to implement a device driver in Pascal. I don't think anybody would.
heater said...
... nearly thirty years ago Borland introduced Turbo Pascal
The "turbo" in Turbo Pascal was because of it's compilation speed, not it's execution speed.
heater said...
"Pascal is a very small language - much like C"
It doesn't make sense to compare just the syntax when things like "readln" and "writeln" are part of the Pascal language. If you did that, you might even conclude that Pascal was in fact a much "bigger" language than C, since it has many more "reserved words" - possibly even more than Ada! But that's nonsense. However, I'd accept that both Pascal and C are "smallish" languages.
As to the other points, I defer to your greater knowledge of current Pascal usage.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Why would you not write a device driver in Pascal?
Yes the "Turbo" referred to Turbo Pascals compilation speed. However it was a lot faster than the pcode systems you were referring to. Modern Pascal compilers are pretty tight.
I just don't like to lump the libraries in with the language. Perhaps that's just a silly personal preference, to my mind "language" (human or computer) encompasses syntax and semantics, "libraries" contain the things you say in that language. And no I don't consider defining functions as adding new words to the language or meanings for old words, except when you get to C++ and such and can at least override the meaning of operators. Or perhaps it comes from years of working on all kinds of systems in various languages where there are no such cosy libraries, the "language" was all we had.
"readln" and "writeln" are not keywords in Pascal they are procedures defined in the system unit, a library.
Where is BradC when I need help with defending Pascal in an argument?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Re Writing a driver in Pascal: Because, Pascal is not a language suitable for "bit twiddling" - and device drivers do a lot of that. Even if Pascal can do it as fast as C (something I would have to be convinced of!) the syntax of the language then comes into play. Once you know C, the "bit twiddling" operators are concise and exact. If you have to read 4 lines of code to achieve the same thing in Pascal, then I don't care if it compiles efficiently - by the time I'm finished reading the lines, the right side of my brain is off admiring the elegance of the syntax while the left side of my brain has fallen asleep from boredom.
Re Lumping the "libraries" in. I go by the standards - If the standards include the libraries in then it's because the language is useless (and completely non-portable) without them. They do that for C, Pascal and Ada - and therefore so do I.
Re "readln" and "writeln": Same difference. They appear in the list of "reseved words" in the standard.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Re: Writing a driver in Pascal
Good answer. I hate to do this in the middle of a good argument but I agree with everything you said about that.
Re: Lumping the "libraries"
Bah! humbug! What do standards writers know about anything, they all ways want to throw a kitchen sink into everything. The only ones I have ever met never actually wrote any code.
I'd rather go with what Chomsky and John Backus had to say about languages. If it's not in the BNF it's not part of the language.
A library function does not exist until you have written it in the language, so how can it be part of the language?
Re: "readln" and "writeln"...They appear in the list of "reseved words" in the standard.
That' interesting because they do not exist in the list of reserved words for Free Pascal in any of it's dialects. www.freepascal.org/docs-html/ref/refse3.html#x11-100001.3
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ok, fair cop - "readln" and "writeln" are indeed not "reserved words" in Pascal - but that's because Pascal does not have "reserved words" as such - this term does not appear in the standard at all. They are instead on the list of "Required Identifiers". And what exactly are "Required Identifers"? - well, here it is from the horses mouth: "Any identifier that is defined in clause 6 as a required identifier shall denote the corresponding required entity by its occurrence in such a program fragment." Which, when you consider that "clause 6" comprises about 80 of the 90 pages of the Pascal standard, kind of smells a bit like "reserved word" to me!
And by the way, clause 6 contains a lot of what looks suspiciously like BNF - including "readln" and "writeln"!
@ErNa,
Yes, and the opcode for WAITCNT could be RSN!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Read again. Clause 6 contains a definition of the parameter list to writeln, but "writeln" itself does not appear in the production rules at all. So whilst writeln is required it is not part of the syntax as defined by the production rules. Therefor it's not part of the language in my book, just another procedure that you have to write somewhere.
6.10.4 The procedure writeln
The syntax of the parameter list of writeln shall be:
writeln-parameter-list = [noparse][[/noparse] '(' (file-variable | write-parameter )
{ ',' write-parameter } ')' ] .
Same goes for readln.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
(geek humor escalation => "There are 100 types of people: those who understand binary, and those who understand bit masks")
SASSY is another good name, but I have to admit that the name SPAM is growing on me.· I'm just concerned that I'll get a letter from Hormel claiming trademark infringement. [noparse]:)[/noparse]· Here in Austin, Texas we have an annual event called Spamarama (·http://spamarama.net ).· It's been held for the past 30 years to celebrate Spam.· There is a cook-off event and the Spamalympics, where people demonstrate their athletic abilities with Spam.
Maybe Hormel's trademark wouldn't apply to a something in a different field.· Considering that the word spam has a completely different meaning in the world of computing it may not be an issue.
Dave
Edit: It looks like Spamarama·hasn't happened during the past 3 years·because of a licensing issue with Hormel.· This illustrates my concerns about using SPAM.
Post Edited (Dave Hein) : 7/23/2010 4:04:11 PM GMT
The 'L' could be for 'Language', as in Spin Language AsseMbly.
What about SPASY (or SPASSY) instead of SPASM?
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
(geek humor escalation => "There are 100 types of people: those who understand binary, and those who understand bit masks")
I'm going to go with SPASM.· I like the sound of it, and I don't think there's any issues with it conflicting with the SPASM that was used on the IBM 360/370 back in the 70's.· The term SPASM is used for other assemblers on PIC and Z80 processors, but I think it is a natural fit for a Spin bytecode assembler.
Comments
Re Floating point: Having to use another cog is quite expensive since cog-to-cog communication has to be via the hub. Also, there is the additional overhead of having to set up the command (and its parameters) in the client cog and then decoding them in the server cog (if your server cog implements more than just one function). Then of course you have to do the same back the other way to pass the result. The cost of invoking a function implemented in another cog can easily double or quadruple the cost of implementing the same function locally. This was a major early design decision in Catalina - i.e. keep everything possible in the kernel cog - and the resulting benefit to things like floating point performance is simply massive.
Re Structures: Do you have a program that disassembles compiled spin binaries into bytecodes? That would be very useful here to see just how many byte codes are generated. If my understanding of SPIN byte codes is correct, Calculating 'pstruct + istruct + x' should take around 8 such byte codes or operands - each of which requires a fetch from hub RAM. However, there is one optimization that you could do immediately - some of those additions don't need to be done at run time. For instance the offset of the field x (i.e. istruct.x) within type Test2 is constant. Keeping track of all field offsets would save you having to recalculate 'istruct +x' on each access - since you actually know where x is within the structure.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
This is obviously not very efficient.· Clearly we don't need to add zero offsets, but it gives you an idea of the operations involved.· I did set the option in BST to fold constants, but it didn't do it for this case.
Dave
It is such a shame we have all these languages which are similar, yet so different, at the most basic level. I mean Basic, C, VB, Pascal to name a few. Spin is just another.
Anyway, that's not progressing this thread and there are exciting ideas being posted here. These discussions are really proposing ideas to take the prop to the next level.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Ah thanks - I forgot about using BST! That byte code is pretty bad - SPIN takes 12 8 instructions to do what PASM can do in 3 (assuming the structure is a local variable). And it takes the same amount almost 2/3 of the RAM space to do it. So much for byte coded solutions being significantly smaller in size.
The "zero offsets" thing only applies to the first field element - if you had chosen another field than 'istruct.x', or the structure was arranged differently, then the offsets being added would not be all zeroes. The "folding constants" option might be able to achieve the optimization I mentioned earlier, bringing the result down from 12 to 8 8 to 6.
Ross.
@Cluso,
So your response to the proliferation of unnecessary languages is to introduce another one?
EDIT: Oops! I keep mis-counting the byte codes! To clarify, the LMM PASM instructions I wanted to compare the SPIN byte code against was a simple fetch from a local structure and a save to a local variable, which in LMM PASM is something like:
I think this takes 8 byte codes and operands. If anyone thinks just leaving the result in a register is somwhow cheating, it isn't - LCC puts local variables in registers wherever possible, so most simple local variables (like loop counters) end up assigned to cog registers. Local structures, however, always exist in the frame, and Dave's actual C code (and sequence of byte codes) also saves the result back into a structure, so a more correct comparison would be something like:
This is what takes 12 SPIN byte codes and operands. However, this is not really a true comparison either, because treating these individually doesn't allow LCC To make the many trivial code optimizations (such as re-using common subexpressions that occur on multiple lines rather than recalculating them). These optimizations are simply not possible in SPIN byte codes (no local storage!) To see this, you might expect Catalina to take 21 instruction longs to execute the following 3 lines of C (taken from Dave's program):
[noparse][[/noparse]quote]
pstruct->istruct.x = gstruct.istruct.x;
pstruct->istruct.y = gstruct.istruct.y;
pstruct->istruct.z = gstruct.istruct.z;
However, the actual generated code is only 15 instruction longs. Even if we assume the SPIN compiler can do constant folding, the same 3 lines of C will take 24 bytes of codes and operands.
This is a good example of how LMM PASM can be expected to approach 2 times byte code size, but is typically much more than twice as fast.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 7/22/2010 8:26:19 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
@Ross, there is certainly value in using C versus Spin.· It has the advantages I mentioned above as well as being higher speed.· The only disadvantge is in cases where a Spin program will fit in 32K of RAM, but the C program won't.· In that case, maybe heater's approach to C would work.· It would be nice to have have a few benchmarks that compare speed and size for the various language options.
I have attached the first draft of a document that defines mnemonics for the Spin bytecodes.· I haven't added the unary opcodes that use the "effect" mode of RAM access.· I'll add those later.· For the most part I use the Spin/PASM opcode name if one exists.· Some other opcodes use fairly long names, such as "framenoret", which I plan on changing to something shorter.· In the case of framenoret, I'll probably call it frame or frm, and call the other frame instruction that supports a return value framer or frmr.
I plan on referring to the Spin assembly language as SASM.· I also thought about using SPASM, which fairly accurately describes my reactions as I dig deeper in Spin bytecodes.· My only concern about using SPASM is that it is a language that I recall from the early·70's.· I don't know if anyone programs in SPASM these days.
There are many opcodes for accessing hub RAM.· I hope my naming techique is straigh-forward enough.· Let me know if it seems confusing.
Dave
Edit: BTW, I have a SASM assembler working that can handle simple programs.· I was able to·assemble a "Hello World" program that runs under spinix.· I need to add DAT support to the assembler to make it really useful.· The assembler is currently 650 lines of C code, which includes a 200-line opcode table.· My plan is to convert the assembler to Spin after I add DAT support.
Post Edited (Dave Hein) : 7/22/2010 6:27:12 PM GMT
SPIN is a great language to learn. But as Dave points out, the most significant reason for also learning a bit about C (even if you choose not to use it) is that you will just keep meeting it again and again - because it is available on every processor ever devised (usually for free), and because so much existing software is written in it. The other reason is that it is probably the closest thing we have to a universal language. By that I mean a platform independent language that can implement any type of algorithm with equal felicity - or (as some people claim) with equal obscurity
@Dave,
I acknowledge the code size of LMM C prgrams compared to SPIN will remain a problem (just not as big a one as many people seem to think!) and that there is room for alternative implementations of C.
By the way, you are missing a great opportunity here - obviously the correct name for a SPIN-based Assembly language designed to rival PASM is ... SPAM!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just read your byte code document. Very neat and logical.
Even though I prefer to program in C, every time I look at SPIN I am simply amazed at just how much functionality Chip manages to squeeze into a single cog! There has to be a way to exploit this effectively for use by more mainstream languages - my feeling is that it is the current emphasis on trying to use it as a vehicle for C is where we are going wrong - it would instead make a better vehicle for "higher level" stack and procedural based languages than the C family (C, C++, C# etc). A few years ago you probably would have said it was ideal platform for implementing languages like Pascal or Modula. In my day (gosh I feel old!) Pascal was the standard "first" language taught by most universities. I wonder what it is these days?
BTW, See www.dotnetmasters.com/HistoryOfCFamily.htm for a nice summary of the members of the C language family.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I'm no language or compiler expert but I make the observation that C and Pascal have much the same data types and much the same control structures. Much the same ideas about functions and parameters etc. In fact as far as I can tell they are pretty much equivalent. As the language gurus say they are both "imperative" or "procedural" programming languages.
A different syntax, sure. Some semantic differences that make it a bit harder to hang you yourself in Pascal. I'm guessing that the code they generate could be quite similar.
So, I don't see why Pascal would be a better source language for Spin byte codes than C.
Perhaps you could elaborate.
In my day at university we had ALGOL (Gosh I am old) the mother of all such languages.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 7/23/2010 1:45:00 AM GMT
Gosh, you are old
I'm not really suggesting Pascal, but I can't think of a better alternative yet. However, while I try and come up with one, I'll try and explain my reasoning a bit more ...
It's partly a matter of expectation. C is a "bit twiddling" language (as evidenced by the inclusion of things like bit fields, bitwise operators, different integer sizes, the deliberate "confusion" between arrays and pointers, pointer arithmetic, the ability to get the address of local variables etc). This leads people to expect to be able to operate at about the same low level - and achieve the same speed - as assembly language. But but this is not really practical in a language implemented using SPIN byte codes. This is why we mostly implement our drivers for the Propeller in PASM and not SPIN (excepting for the relatively slow serial drivers such as SPI and I2C). For example, I'm not aware of any video drivers - even a simple one - written in SPIN (mind you, I'm not aware of any written in C either!).
However, none of these features are present in Pascal, so people don't expect to be able to use Pascal to do such things. If Pascal executed at speeds comparable to SPIN, Pascal programmers (assuming there still are such people) would be perfectly happy. Nobody expects Pascal programs to be blindingly fast - Pascal has a long history of being implemented using a simple "pcode" interpreters, quite similar to the SPIN interpreter.
Pascal found an ideal niche as a teaching language, partly because it was "type safe" - this led to compilers that could generate better diagnostic messages to help programming newcomers identify potential programming problems more easily. Also, Pascal is also a "small" language - much like SPIN - with very simple libraries - this makes a complete and standardized implementation relatively easy.
As I say, I'm not actually suggesting Pascal, but I think there could definitely be advantages to using SPIN byte codes to implement languages other than just SPIN (for which it is obviously very suitable) or C (for which it is not particularly suitable). There's a whole spectrum of languages out there for which SPIN byte codes might be more suitable - there surely must be other languages out there with the right combination of ease-of-use (which Pascal and SPIN both have, but C definitely does not) and low-level features (which SPIN and C both have, but Pascal does not) and speed (which C has, but SPIN and Pascal do not).
Of course, part of the problem is that we're all making our own assumptions about which combination of these factors would suit Parallax best.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Even though SPAM is a good name I'm still thinking of other candidates.· SPASM was the Stanford single pass assembler that ran on the IBM 360.· I realized that SASM is an x86 assembler.· I'm now leaning toward the name SPASE (prounced like space).· I would be interested in any other suggestions for a name.
I've never programmed in Pascal, but I recall several programmers at my work in 1988 preferred it over C.· They felt that C didn't enforce enough structure to make it a reliable programming language like Pascal.· It was too easy to mess up things with a bad pointer in C.· Sounds like the History of C website.
I added support for defining a data area in SPAM/SASM/SPASM/SPASE.· I actually just added the three pseudo-ops byte, word and long, which insert 1, 2 or 4 bytes of data.· They can be added anywhere in the code.· There's really no reason to confine the DAT area to the beginning of the object like Spin does.· Of course, even Spin will insert STRING data within the body of the object.
I did a quick conversion from C to Spin just to see how large the code is.· The Spin version of the assembler is about 10KBytes.· That's without any buffers, but I shouldn't have any problems fitting it into spinix.
Dave
or SPASS, the german word for FUN?
Andy
Ok - if you write a Spin/Pascal/AsseMbly compiler, we'll be all set!
I can see Parallax's new sales campaign now: "Propeller II - now with extra SPAM!"
It can't possibly fail.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Thank you. Old enough to know that you are totally wrong[noparse]:)[/noparse]
I have to pull your statements apart vigorously:
C is a bit twiddleing languge for sure but I'm also sure you will find that anything you can do in C you can do in Pascal. It may lack the language features to express some things directly and cause you to do it in a round about way but I don't think there is a great loss in performance as a result.
See links below.
A lot of pascal programmers would be mightily upset.
I think there is more Pascal programming going on than you imagine. Free Pascal is a thriving project.
Did I mention I am now getting to grips with a large body of Pascal code that absolutely needs speed. It's a simulation system. It needs to be fast.
You should try the Free Pascal compiler, it's blinding fast and it is written in Pascal.
Oh yes, and BradC has written BSTC in Pascal. That's pretty snappy. (Which by the way probably does a lot of bit twiddling what with having to build instruction bit fields and such.
Well except nearly thirty years ago Borland introduced Turbo Pascal which compiled to native code and was pretty "turbo". I think everybody has expected Pascal to have C like speed ever since. I bet there have never been many real programs created with a pcode system.
Actually I would say "Pascal is a very small language - much like C"
I think we had a similar debate going on about C vs C++. In my mind "language" means language as defined by it's syntax and semantics. In that respect C and Pascal are about neck and neck. Whilst ADA, for example, is enormous. "language" does not include the libraries. Yes I know libs get standardized along with the language but I choose to ignore that.
For sure C has a lot stuff in it's libs and Pascal has a lot less. That is not the fault of the language as such. Perhaps if Pascal had become the most commonly used language decades ago it would now have evolved a similarly comprehensive set of libraries.
Pointers in Pascal:
www.freepascal.org/docs-html/ref/refse15.html
Yes OK not for local or global variables.
Function pointers in Pascal:
wiki.freepascal.org/How_To_Use_Function_Pointers
Bit fields in Pascal, see "packed record" here:
en.wikipedia.org/wiki/Comparison_of_Pascal_and_C
Unions in Pascal: See above wiki link.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
"Spam, lovely Spam, wonderful Spam."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 7/23/2010 6:54:25 AM GMT
Ah!, is this the room for an argument?
In the sense that both languages are general purpose languages, I suppose that's true. But I also know I wouldn't choose to implement a device driver in Pascal. I don't think anybody would.
The "turbo" in Turbo Pascal was because of it's compilation speed, not it's execution speed.
It doesn't make sense to compare just the syntax when things like "readln" and "writeln" are part of the Pascal language. If you did that, you might even conclude that Pascal was in fact a much "bigger" language than C, since it has many more "reserved words" - possibly even more than Ada! But that's nonsense. However, I'd accept that both Pascal and C are "smallish" languages.
As to the other points, I defer to your greater knowledge of current Pascal usage.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Why would you not write a device driver in Pascal?
Yes the "Turbo" referred to Turbo Pascals compilation speed. However it was a lot faster than the pcode systems you were referring to. Modern Pascal compilers are pretty tight.
I just don't like to lump the libraries in with the language. Perhaps that's just a silly personal preference, to my mind "language" (human or computer) encompasses syntax and semantics, "libraries" contain the things you say in that language. And no I don't consider defining functions as adding new words to the language or meanings for old words, except when you get to C++ and such and can at least override the meaning of operators. Or perhaps it comes from years of working on all kinds of systems in various languages where there are no such cosy libraries, the "language" was all we had.
"readln" and "writeln" are not keywords in Pascal they are procedures defined in the system unit, a library.
Where is BradC when I need help with defending Pascal in an argument?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Re Writing a driver in Pascal: Because, Pascal is not a language suitable for "bit twiddling" - and device drivers do a lot of that. Even if Pascal can do it as fast as C (something I would have to be convinced of!) the syntax of the language then comes into play. Once you know C, the "bit twiddling" operators are concise and exact. If you have to read 4 lines of code to achieve the same thing in Pascal, then I don't care if it compiles efficiently - by the time I'm finished reading the lines, the right side of my brain is off admiring the elegance of the syntax while the left side of my brain has fallen asleep from boredom.
Re Lumping the "libraries" in. I go by the standards - If the standards include the libraries in then it's because the language is useless (and completely non-portable) without them. They do that for C, Pascal and Ada - and therefore so do I.
Re "readln" and "writeln": Same difference. They appear in the list of "reseved words" in the standard.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Re: Writing a driver in Pascal
Good answer. I hate to do this in the middle of a good argument but I agree with everything you said about that.
Re: Lumping the "libraries"
Bah! humbug! What do standards writers know about anything, they all ways want to throw a kitchen sink into everything. The only ones I have ever met never actually wrote any code.
I'd rather go with what Chomsky and John Backus had to say about languages. If it's not in the BNF it's not part of the language.
A library function does not exist until you have written it in the language, so how can it be part of the language?
Re: "readln" and "writeln"...They appear in the list of "reseved words" in the standard.
That' interesting because they do not exist in the list of reserved words for Free Pascal in any of it's dialects. www.freepascal.org/docs-html/ref/refse3.html#x11-100001.3
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away
Ok, fair cop - "readln" and "writeln" are indeed not "reserved words" in Pascal - but that's because Pascal does not have "reserved words" as such - this term does not appear in the standard at all. They are instead on the list of "Required Identifiers". And what exactly are "Required Identifers"? - well, here it is from the horses mouth: "Any identifier that is defined in clause 6 as a required identifier shall denote the corresponding required entity by its occurrence in such a program fragment." Which, when you consider that "clause 6" comprises about 80 of the 90 pages of the Pascal standard, kind of smells a bit like "reserved word" to me!
And by the way, clause 6 contains a lot of what looks suspiciously like BNF - including "readln" and "writeln"!
@ErNa,
Yes, and the opcode for WAITCNT could be RSN!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Read again. Clause 6 contains a definition of the parameter list to writeln, but "writeln" itself does not appear in the production rules at all. So whilst writeln is required it is not part of the syntax as defined by the production rules. Therefor it's not part of the language in my book, just another procedure that you have to write somewhere.
6.10.4 The procedure writeln The syntax of the parameter list of writeln shall be: writeln-parameter-list = [noparse][[/noparse] '(' (file-variable | write-parameter ) { ',' write-parameter } ')' ] .Same goes for readln.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
(geek humor escalation => "There are 100 types of people: those who understand binary, and those who understand bit masks")
Maybe Hormel's trademark wouldn't apply to a something in a different field.· Considering that the word spam has a completely different meaning in the world of computing it may not be an issue.
Dave
Edit: It looks like Spamarama·hasn't happened during the past 3 years·because of a licensing issue with Hormel.· This illustrates my concerns about using SPAM.
Post Edited (Dave Hein) : 7/23/2010 4:04:11 PM GMT
SLAM would be good if the L had any meaning.
I like SPASM the best though.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
What about SPASY (or SPASSY) instead of SPASM?
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
(geek humor escalation => "There are 100 types of people: those who understand binary, and those who understand bit masks")