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

Homespun Spin compiler 0.31: Now open source

13468912

Comments

  • BradCBradC Posts: 2,601
    edited 2008-09-21 12:52
    mpark said...

    Edit: Version 0.17
    <UL>
    * presence of @@@ disables duplicate object elimination
    </UL>

    I take it this is disabling file/filename based elimination and not object bytecode based ?

    I'm just wondering if this is absolutely required. ?

    Oh, and another bug for you mpark.
    (That caret is pointing at the '"' prior to the colon).

    brad@bklaptop2:~/Objects/FemtoBasic_2008-02-28/FemtoBasic$ mono ~/Desktop/homespun017.exe FemtoBasic.spin 
    Homespun Spin Compiler 0.17
    parsing FemtoBasic.spin
    parsing fsrwFemto.spin
    parsing sdspiFemto.spin
    parsing vga_Drive.spin
    parsing comboKeyboard.spin
    comboKeyboard.spin, line 645: Expected local label
    shift2                  byte    $22, 0, 0, 0, 0, "<_>?)!@#$%^&*(", 0, ":", 0, "+" 
                                                                          ^
    
    

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • hippyhippy Posts: 1,981
    edited 2008-09-21 12:59
    I wouldn't call the caret positioning a bug. It points to the start of the token ( a string ) which isn't as expected. That it doesn't take the string as it did the one before it looks like a bug.
  • BradCBradC Posts: 2,601
    edited 2008-09-21 14:03
    hippy said...
    I wouldn't call the caret positioning a bug. It points to the start of the token ( a string ) which isn't as expected. That it doesn't take the string as it did the one before it looks like a bug.

    Sorry, I was not clear. I was actually indicating where the caret is pointing (on my screen, The forum refuses to monospace and stuffs it up) in order to properly point out the error that homespun generates on that file which is actually valid code.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!

    Post Edited (BradC) : 9/21/2008 2:09:05 PM GMT
  • mparkmpark Posts: 1,305
    edited 2008-09-22 06:22
    Brad -- @@@ disables bytecode based duplicate elimination. The way Homespun works is it knows what order the objects should be in memory but not where, then it compiles the first object at address 0010, now knows how long it is, compiles the second object putting it after the first, and so forth.
    Then bytecode based duplicate elimination occurs, which can move objects around in memory to close up gaps caused by object elimination. Before @@@, this didn't matter, but now some object is going to depend on living at address xxx, and moving it somewhere else will cause much pulling of hair.
    Filename-based duplicate elimination occurs much earlier in the process.
    Maybe your compiler does things in a different way and can avoid the problem.

    Thanks the bug report. I'm vacationing in San Francisco this week, so updates will be sporadic at best.


    m
  • BradCBradC Posts: 2,601
    edited 2008-09-22 07:32
    mpark said...
    Brad -- @@@ disables bytecode based duplicate elimination. The way Homespun works is it knows what order the objects should be in memory but not where, then it compiles the first object at address 0010, now knows how long it is, compiles the second object putting it after the first, and so forth.
    Then bytecode based duplicate elimination occurs, which can move objects around in memory to close up gaps caused by object elimination. Before @@@, this didn't matter, but now some object is going to depend on living at address xxx, and moving it somewhere else will cause much pulling of hair.
    Filename-based duplicate elimination occurs much earlier in the process.
    Maybe your compiler does things in a different way and can avoid the problem.

    Thanks the bug report. I'm vacationing in San Francisco this week, so updates will be sporadic at best.


    m

    Neat, enjoy the vacation.
    My filename dup detection prevents objects being loaded more than once. I compile all the objects once at PBASE=$10, then I do a bytecode compare to eliminate any duplicate objects before writing them out to the image. If I'm generating a list file, or there is an @@@ in there, I will-recompile the objects starting with the top object in image order until the PBASE of each object stops moving around.

    For a list file only, that is once. I need to do this so the list file is generated for the correct PBASE offset.
    For @@@ I tend to do it twice plus an additional for a final compare.

    So I don't write the objects into memory at all until all the duplicates have been removed, but I do need to re-compile them if I'm generating a list file or there is an @@@ somewhere.

    I've left bytecode based dup elimination in place even with @@@. Maybe I ought to disable it also. Perhaps we need feedback from the lads who use @@@.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • PraxisPraxis Posts: 333
    edited 2008-09-22 09:17
    Enjoy your vacation.

    In the meantime I was wondering if you could add the following "Items" to the compiler.
    All items should be parsed as case insensitive.

    Item 1
    
    These additions do not create code and should just be ignored by the compiler and not generate errors etc.
    
    End Con
    End Var
    End Pri
    End Pub
    End Dat
    
    Basically ignore anything that starts with End and has a white space following.
    
    #Region - and anything else on this line.
    #End Region
    
    



    Item 2
    
    Currently all "Spin Objects" are defined as separate files.
    
    The idea here is to have the objects defined in a single file as well, let me know what you think about that.
    
    Object
    End Object
    
    



    Regards

    Post Edited (Praxis) : 9/22/2008 10:02:57 AM GMT
  • SapiehaSapieha Posts: 2,964
    edited 2008-09-22 09:50
    Hi mpark

    """""" You said.....
    Brad -- @@@ disables bytecode based duplicate elimination. The way Homespun works is it knows what order the objects should be in memory but not where, then it compiles the first object at address 0010, now knows how long it is, compiles the second object putting it after the first, and so forth.
    Then bytecode based duplicate elimination occurs, which can move objects around in memory to close up gaps caused by object elimination. Before @@@, this didn't matter, but now some object is going to depend on living at address xxx, and moving it somewhere else will cause much pulling of hair.
    """"""

    I maybe not understand it at al But.
    What not generate separate bytecode objects with Link pseudo code and have elimination in this phase.
    After that Link them in old linker maner with given positons in binary code.

    Sorry if I mising something but I stil learing me what way it works.

    Thanks for this thred and Yours discussion

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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 wont know.
    If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


    Sapieha

    Post Edited (Sapieha) : 9/22/2008 10:05:55 AM GMT
  • BradCBradC Posts: 2,601
    edited 2008-09-22 10:20
    mpark said...
    Before @@@, this didn't matter, but now some object is going to depend on living at address xxx, and moving it somewhere else will cause much pulling of hair.

    Ahh, the penny just dropped. Yes I see how this could be a problem. I get around it by re-compiling the objects if they move.

    It took some major re-engineering as I'd made the assumption that an object would only be compiled once (a rational assumption to make really given the structure of a Propeller object file) and therefore had done nasty things like modifying or removing tokens in-situ.. of course when I went to recompile the object as its absolute address changed, things exploded in my face.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • Cluso99Cluso99 Posts: 18,066
    edited 2008-09-22 13:26
    Brad & Michael,

    I am not sure that there will be a lot of @@@ in a program.

    Just an idea... could you just keep a list of where the @@@ is used and on the final pass fill in the correct values???

    As for duplicate removal, it is not important for me now, but I guess as programs grow in size, it will become more of a requirement. At the moment, I have had to make 2 almost identical versions of the RamInterpreter to prevent duplicate removal. Probably there is another way, but that's what I did (easy way).

    A question... I tried to put my spin DAT code in a separate file and include it. There is no function to include a source file (con, var, obj, dat pub, pri)·and that would be a nice feature. Just insert source statements in situ, no validation. I have not been able to·import the binary using file as it has overhead bytes so it doesnt compile the target address I require when it's included - so no use for me.

    smile.gifsmile.gif

    Post Edited (Cluso99) : 9/22/2008 1:32:30 PM GMT
  • hippyhippy Posts: 1,981
    edited 2008-09-22 14:19
    What you're looking for is #include. At the moment, the only way to do that with PropTool/Propellent is to include it as a sub-object.
  • mparkmpark Posts: 1,305
    edited 2008-09-24 17:09
    OK guys, here's an interim version. I'm taking time out from nibbling on Ghirardelli chocolates in a cable car going across the Golden Gate bridge, so I hope you appreciate this.
    This should fix the ":" problem that Brad found. It also has my first attempt at library paths. It'll look for an environment variable called SPINLIB. It also takes paths on the command line with the -L option (or /L -- options can now begin with - or /).
    E.g.
    set spinlib=q:\blorb;\Program Files\Parallax Inc\Propeller Tool v1.05.5
    homespun017x test /L..\mylib /Lc:\myotherlib\

    It'll print out extra stuff (preceded by //) to tell you what it's doing. That'll go away but for now see if it does what you think it should do.
    Edit: deleted attachment

    Post Edited (mpark) : 10/3/2008 9:28:21 AM GMT
  • mparkmpark Posts: 1,305
    edited 2008-09-25 16:08
    Praxis -- what do you have in mind for that "END <whatever>" you requested? An "END" could appear at the start of any line and the line would be ignored? So it would be kinda like a BASIC REM comment?
  • PraxisPraxis Posts: 333
    edited 2008-09-25 16:16
    Hi MPARK,

    Just these statements:

    End Con
    End Var
    End Pri
    End Pub
    End Dat

    End IF
    End Case
    End Repeat

    #Region
    #End Region

    To be ignored.
  • BradCBradC Posts: 2,601
    edited 2008-09-25 19:46
    Ewwwwww .. why complicate a perfectly acceptable and simple grammar with garbage like that ??
    If they are to be ignored, just leave them out.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • mparkmpark Posts: 1,305
    edited 2008-09-26 07:25
    I'm inclined to agree, but Praxis must have some purpose for this. Something IDE-related? Please let us in on why you want to mess up the grammar, Praxis!
  • PraxisPraxis Posts: 333
    edited 2008-09-26 12:48
    @maprk: Something IDE-related?

    Good guess

    If it is not too much trouble to allow for it.

    I elaborate more once I have done a bit more work.

    Cheers
  • mparkmpark Posts: 1,305
    edited 2008-10-03 10:50
    Version 0.18 now in first post.
    • library search paths (as introduced in 0.17x)
    • #define (simple text replacement)
    • #ifdef/#elseifdef/#else/#endif (conditional compilation)
    • improved memory dump (including crude Spin bytecode disassembly)
    • warns on data truncation
    • for Praxis: Homespun ignores lines that begin with #region or #end. Show me what you can do with this!

    See http://propeller.wikispaces.com/Homespun+Spin+Compiler·for details.
  • Cluso99Cluso99 Posts: 18,066
    edited 2008-10-03 11:40
    Fantastic - I have just checked the listing output - it is perfect for doing full debugging back to source level, both in pasm and spin.

    Now to find the time to do just that, after I complete the interpreter.
  • BradCBradC Posts: 2,601
    edited 2008-10-03 12:13
    mpark said...

    <LI>#define (simple text replacement)
    <LI>#ifdef/#elseifdef/#else/#endif (conditional compilation)
    <LI>improved memory dump (including crude Spin bytecode disassembly)

    Nice.. really, really nice.. gives me something to aspire to [noparse]:)[/noparse] (Or imitate!)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • heaterheater Posts: 3,370
    edited 2008-10-03 12:52
    There are those of us who like to have our control constructs delimited with braces or keywords rather than relying on indentation.
    I've many times managed to screw up program fragments when copy and pasting them around within a project or between programs as the indentation levels did not match. It's even worse pasting into a different editor or platform etc.

    This must be an issue for many as otherwise cntrl-I would not exist in the Spin tool.

    So I would welcome Endxxx statements, especially if they were NOT just ignored but actually did what they say.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • BradCBradC Posts: 2,601
    edited 2008-10-03 13:01
    heater said...
    There are those of us who like to have our control constructs delimited with braces or keywords rather than relying on indentation.
    I've many times managed to screw up program fragments when copy and pasting them around within a project or between programs as the indentation levels did not match. It's even worse pasting into a different editor or platform etc.

    This must be an issue for many as otherwise cntrl-I would not exist in the Spin tool.

    So I would welcome Endxxx statements, especially if they were NOT just ignored but actually did what they say.

    If you change the grammar to that degree, then it will cease to be SPIN really. If you start to implement major changes to the grammar like that, how do you differentiate between Parallax compatible code and code with "relaxed" whitespace requirements but non-spin block styles?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • mparkmpark Posts: 1,305
    edited 2008-10-03 15:59
    BradC said...
    ...

    Nice.. really, really nice.. gives me something to aspire to [noparse]:)[/noparse] (Or imitate!)

    Seems only fair, considering what I'm thinking of imitating from you.
  • mparkmpark Posts: 1,305
    edited 2008-10-03 16:05
    Cluso99 said...
    Fantastic - I have just checked the listing output - it is perfect for doing full debugging back to source level, both in pasm and spin.

    Glad you could decipher it! I was afraid it would only make sense to me.
  • agodwinagodwin Posts: 72
    edited 2008-10-03 16:18
    BradC said...

    If you change the grammar to that degree, then it will cease to be SPIN really. If you start to implement major changes to the grammar like that, how do you differentiate between Parallax compatible code and code with "relaxed" whitespace requirements but non-spin block styles?

    You're right : if you don't follow Spin syntax you might as well use something else entirely.

    But heater's got a good point too - I agree that the indented block structuring is downright evil. It was ugly when they did it in Occam (I think Leon's got some experience of that ?) but at least Occam had an editor that tried to support it by allowing blocks to be folded away. It's far too easy to delete a line or two and accidentally enclose the following lines in an old block.

    I dislike the need to comment out line-ends in Spin, too.

    However, I do find the End xx syntax a bit verbose. Do you have #define to replace it with '}' ?


    Here's a possible solution :

    Since block-indentation is pretty hard to live with unless the editor supports it, and if you're using an alternate compiler you probably aren't using Parallax's IDE, it seems to me that you want free-format input and an intermediate form that's strictly spin. So write the extensions as a preprocessor : the input could be generated with any whitespace, block delimiters, free linewrap, #if directives etc. but the output, if not sent direct to the compiler, would be reformatted to conform to spin block structure and have the conditional parts removed. That output could also then be handled by Parallax's spin compiler directly.

    Post Edited (agodwin) : 10/3/2008 4:35:06 PM GMT
  • SapiehaSapieha Posts: 2,964
    edited 2008-10-03 16:29
    Hi mpark.

    Very fine listings THANKS but litle Error report on command line parameters.

    """"
    Homespun Spin Compiler 0.18
    More than one input file specified
    """"
    With long Names space separated. If I edit name with no spaces al funktions correct

    H:\Arbets\_Div Spin Code\-_ HardWare\HardWare\Homespun Spin compiler>homespun018
    .exe /w /d FullDuplexSerial Chip Gracey 4 in 1.spin > FullDuplexSerial Chip Grac
    ey 4 in 1.list

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • hippyhippy Posts: 1,981
    edited 2008-10-03 16:40
    Always a hard one to say how far a language should change from its official syntax to what people prefer. I was not looking forward to an 'indented language' but haven't had too many problems other than accidentally messing that up, usually with cut and paste.

    One which often gets me is - "repeat var from start to finish"

    Why not - "repeat var := start to finish" ?

    or, as I always use until the syntax error - "for var := start to finish" ?

    I also fall over "repeat while expr", treating 'repeat' being entirely superfluous except it means something else if a 'repeat' is dropped above it as a 'stop here' bebugging attempt.
  • mparkmpark Posts: 1,305
    edited 2008-10-03 17:04
    Sapieha, try putting quotation marks (") around your filenames-with-spaces:

    homespun018.exe /w /d "FullDuplexSerial Chip Gracey 4 in 1.spin" > "FullDuplexSerial Chip Gracey 4 in 1.list"

    I don't think this problem is limited to Homespun. Allowing spaces in filenames is a terrible idea, imho.
  • mparkmpark Posts: 1,305
    edited 2008-10-03 17:11
    Heater, Brad, hippy -- interesting thoughts.

    Don't forget, Spin syntax does allow you to delimit blocks with braces. Might not do what you want though.
  • agodwinagodwin Posts: 72
    edited 2008-10-03 17:25
    hippy said...

    One which often gets me is - "repeat var from start to finish"

    Why not - "repeat var := start to finish" ?

    or, as I always use until the syntax error - "for var := start to finish" ?

    Executing that loop for the value of finish is kind of awkward, too - Spin has quite a bit of support for 1-based variables (e.g. through lookup and lookupz) but arrays are zero-based. So iterating over an array means

    con
    arraysize = 10

    var
    long array[noparse][[/noparse]arraysize]

    pub
    repeat i from 0 to arraysize-1
    array := something


    Which is a pain because, AIUI, arraysize-1 is computed at runtime. Maybe even on every loop.

    I suppose the answer is to use the 'constant' operator, though it's an optimisation I'd expect the compiler to do on it's own.

    [noparse][[/noparse]sorry .. indentation lost. You know what I mean .. ]
  • BradCBradC Posts: 2,601
    edited 2008-10-04 06:21
    agodwin said...

    Which is a pain because, AIUI, arraysize-1 is computed at runtime. Maybe even on every loop.

    I suppose the answer is to use the 'constant' operator, though it's an optimisation I'd expect the compiler to do on it's own.

    [noparse][[/noparse]sorry .. indentation lost. You know what I mean .. ]

    bstc will calculate those as a constant if you enable constant folding (-Oc).
    I don't default to doing that as my test harness relies on the bytecode being bit for bit compatible with the Parallax compiler.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
Sign In or Register to comment.