Shop Learn P1 Docs P2 Docs
Homespun Spin compiler 0.31: Now open source - Page 9 — Parallax Forums

Homespun Spin compiler 0.31: Now open source

16791112

Comments

  • PraxisPraxis Posts: 333
    edited 2008-10-26 20:01
    Hi Michael,

    This caused the following error:

    gDemo.spin -b -w -i0 -d -L D:\Program Files\Parallax Inc\Propeller Tool v1.2

    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
  • agodwinagodwin Posts: 72
    edited 2008-10-26 20:45
    It's a valid windows path, but not a valid way to specify it in the windows shell.
    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.
  • PraxisPraxis Posts: 333
    edited 2008-10-26 20:59
    @agodwin: Yep I agree about the spaces in paths/filenames.
  • mparkmpark Posts: 1,266
    edited 2008-10-27 07:47
    Version 0.24 in first post.

    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.
  • SapiehaSapieha Posts: 2,964
    edited 2008-10-27 07:58
    Hi mpark.

    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
  • mparkmpark Posts: 1,266
    edited 2008-10-27 08:12
    Ooops. Now it should be there. Thanks Sapieha.
  • ImageCraftImageCraft Posts: 348
    edited 2008-10-27 08:26
    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.
  • agodwinagodwin Posts: 72
    edited 2008-10-27 10:43
    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'.
  • BradCBradC Posts: 2,601
    edited 2008-10-27 11:52
    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.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • PraxisPraxis Posts: 333
    edited 2008-10-27 13:05
    BradC said...

    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 magine if you will.............Macros!!

    Just some random thoughts.

    Cheers

    Post Edited (Praxis) : 10/27/2008 1:29:09 PM GMT
  • mparkmpark Posts: 1,266
    edited 2008-10-27 16:56
    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.
  • PraxisPraxis Posts: 333
    edited 2008-10-27 16:57
    Can you make the extension for non standard xxx.spasm?
  • mparkmpark Posts: 1,266
    edited 2008-10-27 17:01
    Sure, that's a possibility. Any other suggestions?
  • PraxisPraxis Posts: 333
    edited 2008-10-27 17:03
    No realy but as the IDE already supports a project type that uses xxx.spasm as file type I like you am lazy about making changes[noparse]:)[/noparse]
  • mparkmpark Posts: 1,266
    edited 2008-10-27 17:35
    What's inside existing .spasm files? I wouldn't want to create more incompatibilities.
  • PraxisPraxis Posts: 333
    edited 2008-10-27 17:43
    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.
  • M. K. BorriM. K. Borri Posts: 279
    edited 2009-01-26 00:37
    MEOW this is shiny. [noparse]:D[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    http://forums.parallax.com/showthread.php?p=650217

    meow, i have my own topic now? (sorta)
  • heaterheater Posts: 3,370
    edited 2009-04-29 21:31
    BUG;

    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.
  • mparkmpark Posts: 1,266
    edited 2009-04-29 23:02
    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?
  • heaterheater Posts: 3,370
    edited 2009-04-30 13:30
    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.
  • mparkmpark Posts: 1,266
    edited 2009-05-13 19:39
    Version 0.25x in first post.

    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.
  • RossHRossH Posts: 4,907
    edited 2009-05-13 23:01
    All,

    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.
  • mparkmpark Posts: 1,266
    edited 2009-10-05 05:04
    Version 0.27 posted at top of thread. Bug fixes.
  • hippyhippy Posts: 1,981
    edited 2009-10-09 00:37
    @ 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 ...

    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.
  • Mike GreenMike Green Posts: 23,101
    edited 2009-10-09 01:36
    hippy,
    I think you can use JMPRET with NR to do what you want.
  • mparkmpark Posts: 1,266
    edited 2009-10-09 03:57
    Hi Hippy. I think I can add "svc" without too much difficulty next time I look at Homespun.
  • hippyhippy Posts: 1,981
    edited 2009-10-09 17:05
    @ Mike : I can indeed. Thanks for that. You can tell I've got a bit rusty.

    @ Michael : No need to add to Homespun now if you don't want.
  • mparkmpark Posts: 1,266
    edited 2009-10-09 17:15
    I'll hold off on svc for now. Let us know if jmpret doesn't work out for you.
  • jazzedjazzed Posts: 11,803
    edited 2010-11-26 14:18
    Michael (mpark),

    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?
  • Cluso99Cluso99 Posts: 18,063
    edited 2010-11-27 22:52
    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.
Sign In or Register to comment.