I think I've got Homespun matching Proptool now, at least as far as agodwin's numbers.spin case goes. I still think Proptool is wrong, but what can one do?
Since I was holding my nose anyway, I added the equally distasteful (to me) "0x" prefix for hex numbers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
I don't use Spin so this is not an issue for me per se, but... I don't know, one of the strength of a standard language is that it is standard. Even for embedded programming where a lot of hardware bits are being pushed, a good majority of embedded C programs are portable or at least written in a portable manner. Adding enhancements and differences in an incompatible way, no matter how wrong one thinks the original decision or oversight is, is ... just wrong.
It's tough to do, but I think I agree - - there are a few things I find irritating about Spin due to my C background (and I guess C isn't perfect either) but I don't think it needs dialects. We get enough of that with assemblers.
If there are enhancements that are worth doing (and there are a lot that would help make code maintainable - not just style things that one person or another has grown used to) then I think they should be done with a preprocessor. That way, the preprocessor can be always used to generate 'standard spin'.
ImageCraft said...
I don't use Spin so this is not an issue for me per se, but... I don't know, one of the strength of a standard language is that it is standard. Even for embedded programming where a lot of hardware bits are being pushed, a good majority of embedded C programs are portable or at least written in a portable manner. Adding enhancements and differences in an incompatible way, no matter how wrong one thinks the original decision or oversight is, is ... just wrong.
I agree wholeheartedly. By adding little incompatibilities (and changing the accepted numeric input format serves zero purpose in improving the language, it's purely stylistic) you end up fragmenting the community. The huge advantage new users see with the propeller is the library of available, usable code. By allowing alterations that make it incompatible with the reference compiler you break that and ensure that any code you write is not suitable for use on other systems.
Adding enhancements (like the array operator mpark did, or @@@) for special cases with limitations I can see as acceptable, as they won't be used by the majority of users and certainly not in code generic enough to be added to the Obex. Spin is spin, as soon as you make it incompatible with the parallax compiler it ceases to be spin and becomes something completely different.
I agree wholeheartedly. By adding little incompatibilities (and changing the accepted numeric input format serves zero purpose in improving the language, it's purely stylistic) you end up fragmenting the community. The huge advantage new users see with the propeller is the library of available, usable code. By allowing alterations that make it incompatible with the reference compiler you break that and ensure that any code you write is not suitable for use on other systems.
Yes adding 0x is stylistic but as long as the compiler is backward compatible, so what. Anyway the 0x is not a change but an addition.
Your point hinges around the OBEX as being "the standard" for community library modules but tell me how times have you modified a library oject for some particular function or need and besides how many would upload code known to be incompatible with the reference compiler without some sort of notice that the code will only compile with compiler xx etc when you consider that people who upload want other people to be able to use it.
BradC said...
Adding enhancements (like the array operator mpark did, or @@@) for special cases with limitations I can see as acceptable, as they won't be used by the majority of users and certainly not in code generic enough to be added to the Obex. Spin is spin, as soon as you make it incompatible with the parallax compiler it ceases to be spin and becomes something completely different.
It seems to me with this comment you are arguing your own conclusion above.
The array operator mpark did, or @@@ is definately out of the ball park where the reference compiler is concerned yet you assume that it will not be uploaded to the OBEX, what if it was??
Here's a thought, will the exisiting OBEX be compatible with that mythical beast known as the PropII or will Parallax be leading us into the promised land of sin, debauchery and incompatible Spin. http://forums.parallax.com/showthread.php?p=746473
I think what I'll do is make is so that if you want to use non-standard extensions, you have to call your source file xxx.hspin (or somesuch) rather than xxx.spin. Files ending in .spin will contain only standard Spin.
At this time the IDE spasm project type is a place holder and uses the extention .spasm.
The idea for spasm files was to be able to have non-standard spin extentions like what I have requested and the changes you have made etc as well as pasm, hence the name SPin + pASM.
This sorts out the issue of incompatibilites for spin such as you recenlty sugessted.
What you suggested i.e. differentiate based on the file extention would allow the inclusion of spin lib objects to be compiled as well.
Unhandled Exception: System.IndexOutOfRangeException: Array index is out of range.
at Homespun.ObjectFileSymbolTable.WriteDatBytes (Int32 dp, Int32 size, Int32 data) [noparse][[/noparse]0x00000]
at Homespun.ObjectFileSymbolTable.DatPass2 () [noparse][[/noparse]0x00000]
at Homespun.GlobalSymbolTable.CompileAll () [noparse][[/noparse]0x00000]
at Homespun.Blah.Compile (System.String filename) [noparse][[/noparse]0x00000]
at Homespun.Blah.Main (System.String[noparse]/noparse args) [noparse][[/noparse]0x00000]
Is the symbol table full?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That's different from what you posted in Brad's thread. Please email me a repro for either or both (not that I promise to do anything...)
What version of Homespun are you using?
Yep, that's a different bug. See how confused I am.
Anyway this case is not a major panic. It's something to do with including too much stuff with "file" statements. My "correct" program compiles and runs fine. My incorrect program, with an extra erroneous "file" statement causes the exception. Syntactically I think it is still OK but it might just be that extra file data that is overflowing the Props memory limit.
I'm trying to make a minimalist program to demonstrate this for you.
Edit: Version 024.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
As Michael says, expect a new release of Catalina with XMM support in the next couple of days. That release will require the 0.25x version of Homespun to compile PASM programs larger than 32K.
Many thanks to Michael for his excellent Homespun program and his continued support and assisntance.
@ Michael : An enhancement request for LMM/PASM opcodes ...
Is it possible to add something to allow "jmp literal,#label' ?
This would drop the 9-bit literal value into the otherwise unused <dst> part of the 'jmp' opcode. This is very useful when calling a VM kernel and it's wanted to pass a value ( or register identifier ) to the kernel handler. It can have a different name to 'jmp' to make syntax handling easier ( I've always liked "svc" for SuperVisor Call - but #define can rename so anything will do ) and even a switch to enable its use. Ideally I'd like ...
Note 's' and 'd' operands are swapped to normal PASM, immediate bit is always set, and the 'd' and '#d' options are mainly cosmetic to make generated LMM source more readable where operation can depend on bit 9 setting of the <dst> ...
svc ADD,r0
svc ADD,#255
No rush and I'm open to alternative suggestions. If Homespun already supports something like this then apologies for having not noticed.
I have a request. As you know Catalina uses homespun for compiling SPIN. Adding new platforms in Catalina is quite difficult (PITA).
The best thing that could happen to solve the adding new platforms problem is to allow for an "#include" directive (BSTC could surely use it too). Having fully functional ifdef/elseifdef/else implementation would also help.
I request that you either provide an "#include" feature or release the source code. If you've already opened the source I missed it.
Why is #include so important? Well, the same blob of PASM in Catalina is necessary in about 7 different files. As you know the object concept doesn't really help and copy/paste is painful.
The GNU cpp can be used to include code (I.E. cpp -P --traditional-cpp [options] file), but the entire target source tree would have to be rewritten to use cpp effectively.
Steve (jazzed): ifdef is already available but the implementation is different to bst in that bst runs a hierarchy through child files whereas in homespun it is only active for the current file. IIRC homespun also has a replace directive but cannot recall the syntax.
Comments
This caused the following error:
gDemo.spin -b -w -i0 -d -L
Homespun Spin Compiler 0.23
More than one input file specified
It's the spaces in the path string causing the problem, but as you see it is valid windows path.
Cheers
You need to quote it :
gDemo.spin -b -w -i0 -d -L "D:\Program Files\Parallax Inc\Propeller Tool v1.2"
this is a problem for any operating system with a command-line parser; it's best not to put spaces in filenames.
I think I've got Homespun matching Proptool now, at least as far as agodwin's numbers.spin case goes. I still think Proptool is wrong, but what can one do?
Since I was holding my nose anyway, I added the equally distasteful (to me) "0x" prefix for hex numbers.
Gack. I need a shower now.
In first post is still 23
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
If there are enhancements that are worth doing (and there are a lot that would help make code maintainable - not just style things that one person or another has grown used to) then I think they should be done with a preprocessor. That way, the preprocessor can be always used to generate 'standard spin'.
I agree wholeheartedly. By adding little incompatibilities (and changing the accepted numeric input format serves zero purpose in improving the language, it's purely stylistic) you end up fragmenting the community. The huge advantage new users see with the propeller is the library of available, usable code. By allowing alterations that make it incompatible with the reference compiler you break that and ensure that any code you write is not suitable for use on other systems.
Adding enhancements (like the array operator mpark did, or @@@) for special cases with limitations I can see as acceptable, as they won't be used by the majority of users and certainly not in code generic enough to be added to the Obex. Spin is spin, as soon as you make it incompatible with the parallax compiler it ceases to be spin and becomes something completely different.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Yes adding 0x is stylistic but as long as the compiler is backward compatible, so what. Anyway the 0x is not a change but an addition.
Your point hinges around the OBEX as being "the standard" for community library modules but tell me how times have you modified a library oject for some particular function or need and besides how many would upload code known to be incompatible with the reference compiler without some sort of notice that the code will only compile with compiler xx etc when you consider that people who upload want other people to be able to use it.
It seems to me with this comment you are arguing your own conclusion above.
The array operator mpark did, or @@@ is definately out of the ball park where the reference compiler is concerned yet you assume that it will not be uploaded to the OBEX, what if it was??
Here's a thought, will the exisiting OBEX be compatible with that mythical beast known as the PropII or will Parallax be leading us into the promised land of sin, debauchery and incompatible Spin. http://forums.parallax.com/showthread.php?p=746473
I magine if you will.............Macros!!
Just some random thoughts.
Cheers
Post Edited (Praxis) : 10/27/2008 1:29:09 PM GMT
The idea for spasm files was to be able to have non-standard spin extentions like what I have requested and the changes you have made etc as well as pasm, hence the name SPin + pASM.
This sorts out the issue of incompatibilites for spin such as you recenlty sugessted.
What you suggested i.e. differentiate based on the file extention would allow the inclusion of spin lib objects to be compiled as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://forums.parallax.com/showthread.php?p=650217
meow, i have my own topic now? (sorta)
As mistakenly posted in the bst thread, woops:
Unhandled Exception: System.IndexOutOfRangeException: Array index is out of range.
at Homespun.ObjectFileSymbolTable.WriteDatBytes (Int32 dp, Int32 size, Int32 data) [noparse][[/noparse]0x00000]
at Homespun.ObjectFileSymbolTable.DatPass2 () [noparse][[/noparse]0x00000]
at Homespun.GlobalSymbolTable.CompileAll () [noparse][[/noparse]0x00000]
at Homespun.Blah.Compile (System.String filename) [noparse][[/noparse]0x00000]
at Homespun.Blah.Main (System.String[noparse]/noparse args) [noparse][[/noparse]0x00000]
Is the symbol table full?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
What version of Homespun are you using?
Anyway this case is not a major panic. It's something to do with including too much stuff with "file" statements. My "correct" program compiles and runs fine. My incorrect program, with an extra erroneous "file" statement causes the exception. Syntactically I think it is still OK but it might just be that extra file data that is overflowing the Props memory limit.
I'm trying to make a minimalist program to demonstrate this for you.
Edit: Version 024.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
This version is necessary for Catalina users who want to use XMM. Expect an update from Ross.
This is an optional upgrade for non-Catalina users. It fixes a few tiny bugs and adds a way to specify the output filename.
As Michael says, expect a new release of Catalina with XMM support in the next couple of days. That release will require the 0.25x version of Homespun to compile PASM programs larger than 32K.
Many thanks to Michael for his excellent Homespun program and his continued support and assisntance.
Ross.
Is it possible to add something to allow "jmp literal,#label' ?
This would drop the 9-bit literal value into the otherwise unused <dst> part of the 'jmp' opcode. This is very useful when calling a VM kernel and it's wanted to pass a value ( or register identifier ) to the kernel handler. It can have a different name to 'jmp' to make syntax handling easier ( I've always liked "svc" for SuperVisor Call - but #define can rename so anything will do ) and even a switch to enable its use. Ideally I'd like ...
010111 0001 cccc 000000000 sssssssss : svc s
010111 0001 cccc ddddddddd sssssssss : svc s,d
010111 0001 cccc 1dddddddd sssssssss : svc s,#d
Note 's' and 'd' operands are swapped to normal PASM, immediate bit is always set, and the 'd' and '#d' options are mainly cosmetic to make generated LMM source more readable where operation can depend on bit 9 setting of the <dst> ...
svc ADD,r0
svc ADD,#255
No rush and I'm open to alternative suggestions. If Homespun already supports something like this then apologies for having not noticed.
I think you can use JMPRET with NR to do what you want.
@ Michael : No need to add to Homespun now if you don't want.
I hope you had a happy thanksgiving.
I have a request. As you know Catalina uses homespun for compiling SPIN. Adding new platforms in Catalina is quite difficult (PITA).
The best thing that could happen to solve the adding new platforms problem is to allow for an "#include" directive (BSTC could surely use it too). Having fully functional ifdef/elseifdef/else implementation would also help.
I request that you either provide an "#include" feature or release the source code. If you've already opened the source I missed it.
Why is #include so important? Well, the same blob of PASM in Catalina is necessary in about 7 different files. As you know the object concept doesn't really help and copy/paste is painful.
The GNU cpp can be used to include code (I.E. cpp -P --traditional-cpp [options] file), but the entire target source tree would have to be rewritten to use cpp effectively.
Any thoughts?