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

Homespun Spin compiler 0.31: Now open source

145791012

Comments

  • BradCBradC Posts: 2,601
    edited 2008-10-04 06:24
    mpark said...
    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.

    I'm with Michael here. Spaces in filenames/dirnames cause all sorts of ambiguous issues when parsing paths.
    On Non-Windows OS you can use a quote character '\' before the space, but the easy way to do it is put the file/path name in quotes like was suggested above.

    bstc has exactly the same problem with spaces in names. It's not an easy problem to solve (particularly across platforms that use different path delimiters '\' '/')

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • BradCBradC Posts: 2,601
    edited 2008-10-04 06:35
    mpark said...
    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.

    I was thinking if you took away the indent sensitivity and added begin / end blocks you would pretty much have a variant of pascal syntax.

    I know hippy did some early work on a pascal compiler/runtime for the prop. I wonder how hard it would be do build a limited pascal parser (that is easy) that generated spin bytecode.
    Strings are where this would likely fall down, but the rest of the pascal operators a pretty "spinish".

    My thoughts were rather than keep "extending" or mangling spin to make it fit what people want (which just drifts further and further away from the Parallax reference) was to develop a new sytnax based from SPIN using a different block identifier. You would only need one. No need to differentiate between PUB and PRI. Personally I was drifting toward a BAS block that used some form of familiar BASIC syntax. The spin interpreter has all the primitives required to do goto/gosub, it would just be a matter of syntax.

    I've not touched basic since my apple ][noparse][[/noparse] back in the mid 80's though, so it's something I'd need to look at closely. I did think of buying a basic stamp II to try and get familiar with, but then it's on the end of a long list [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • Cluso99Cluso99 Posts: 18,063
    edited 2008-10-04 07:06
    My 2c

    I always indent my code in VB so that wasn't a problem for me. I thought the indent idea was great for beginners. However, I have been trapped by cutting and pasting or just commenting a line.

    However, if you were going to remove the indentation requirement (and alternative option, not replacement), I would also suggest a slight syntax change to be more like VB or C. Take for example the "if then" construct and "endif". It makes sense to me to make it more like other languages rather than the subtle differences which are present now. I like Brad's suggestion of an alternative to PUB/PRI like BAS. I am not so sure on the "BAS" though I can't think of anything better.

    Don't change the maths symbols such as <<, etc. This is part of spin. Then I think it would be easy to write a module to convert back and forth from one form to the other.
  • PraxisPraxis Posts: 333
    edited 2008-10-04 10:15
    agodwin said...

    I agree that the indented block structuring is downright evil.

    I am still laughing at that quote but it echos my thoughts exactly, indentation for code readability is fine and should be the paradigm, indentation for code function is another mater entirely.

    As you guys are probably aware I am writing a development platform (glorified way of saying editor) for propeller development.
    To leverage the best functionality for the development platform would require some changes to the spin syntax.

    I would therefore propose a "enhanced" syntax for spin and as long as the compiler is backward compatible with the current spin syntax there should be no issue.

    Lets call it SpinX though I am partial to the name Spasm (includes pasm) goes something like this:

    Pub|Pri Sub(values etc) ' Subroutine where no value returned
    
    'Local variables declared as:
    Var X
    Var Y := 0 'can be initialized with a value
    
    End Sub
    
    Pub|Pri Func(values etc) ' Function where value returned
    
    'Local variables declared as:
    Var X
    Var Y := 0 'can be initialized with a value
    
    RETURN whatever
    
    End Sub
    
    'Other blocks
    
    If            End If
    Select        End Select
    Repeat        End Repeat ' block repeat
    Dat           End Dat
    Con           End Con
    Var           End Var
    Obj           End Obj
    
    



    A command line switch for the compiler would be sufficient to enable compiling for the new syntax.

    I would like to add something akin to the object browser in VS to the development platform as well as intellesense and object context prompts. Anyone who has used VS will understand the convenience of these features.

    Any thoughts on = versus := ??

    Cheers

    Post Edited (Praxis) : 10/4/2008 10:21:35 AM GMT
  • BradCBradC Posts: 2,601
    edited 2008-10-04 10:42
    Praxis said...
    agodwin said...

    I agree that the indented block structuring is downright evil.

    I am still laughing at that quote but it echos my thoughts exactly, indentation for code readability is fine and should be the paradigm, indentation for code function is another mater entirely.

    As you guys are probably aware I am writing a development platform (glorified way of saying editor) for propeller development.
    To leverage the best functionality for the development platform would require some changes to the spin syntax.

    I would therefore propose a "enhanced" syntax for spin and as long as the compiler is backward compatible with the current spin syntax there should be no issue.

    My problem with this is if people start widely adopting the "enhanced" (read that as butchered) syntax, then the code becomes incompatible with the existing Spin Tools and Object exchange. You lose the ability to be able to just include existing spin objects (as they use the official format) and you have problems interchanging code with people who use other variants.

    <snipped>

    --
    Brad (Member of the Popular Peoples Front of Judea! Splitters!!)

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

    Post Edited (BradC) : 10/4/2008 10:58:49 AM GMT
  • PraxisPraxis Posts: 333
    edited 2008-10-04 10:57
    @BradC: Be that as it may then please suggest how to do code folding without something to indicate the end of a block?

    Also note that I was thinking about an import function for existing spin code.

    Want to make a nice omelette you gotta break some eggs!

    Post Edited (Praxis) : 10/4/2008 11:07:52 AM GMT
    904 x 684 - 31K
  • BradCBradC Posts: 2,601
    edited 2008-10-04 11:11
    Praxis said...
    @BradC: Be that as it may then please suggest how to do code folding without something to indicate the end of a block?

    Also note that I was thinking about an import function for existing spin code.

    Want to make a nice omelette you gotta break some eggs!

    Ahh, you need to do a cursory parse of the code to get the block start and end points. Same for your syntax highlighting. You really need to be able to do a basic parse of the syntax to identify the relevant components. It's not hard, it just means more work on your part, however it completely removes the need to butcher the syntax to work around a limitation in the ide.

    I guess it's either "Pain for one and gain for many" or "Gain for one and Pain for many".

    You can do it. Parallax did with their syntax highlighter and Ctrl-I block intent indicator.

    Of course doing highlights and block folding with C is easy, there are already many, many highlighters available...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • Cluso99Cluso99 Posts: 18,063
    edited 2008-10-04 11:25
    If Chip didn't want to do the design his own way, we wouldn't have ended up with a great Propeller Chip.

    Years ago a friend of mine re-wrote an assembler for the mini we programmed. It added all kinds of additional features that he wanted and had been asking the manufacturer for for years. The manufacturer's version was free and his cost a few thousand $ per licence. Within a couple of years, the manufacturer was using his assembler (world-wide) for all their own development software.

    So, make the improvements to spin. Please keep backward compatability. We will then have the best of both worlds.

    For Select / End Select may I suggest you allow Case / End Case as well. I always hated Select as I thought Case was more readable.

    So just go for it and thanks for giving us an alternative.
  • hippyhippy Posts: 1,981
    edited 2008-10-04 13:17
    BradC said...
    I know hippy did some early work on a pascal compiler/runtime for the prop. I wonder how hard it would be do build a limited pascal parser (that is easy) that generated spin bytecode.

    Should be possible but I've moved away from a pure Pascal compiler. Mostly the differences in languages are purely decorative, different words, slightly different order of things, but they are all easily translatable to Spin. My vision now is a unified compiler which would take Spin, C, Pascal, and Basic source inter-mixed. The trigger is what the opening word was for the method; "PUB"/"PRI", "PROCEDURE"/"FUNCTION", "SUB"/"DEF", or a type definition for C then parse that entire method using the applicable syntax.

    To make it easy to implement the programmer is forced to use the types Spin uses so parameters and locals have to be type "int" etc or they get an error. It is possible to allow word and byte by masking and extending where variables are used but not absolutely necessary.

    It wouldn't be true C, Pascal or Basic, but Spin in that language's clothing. That seems to be what people are really after or would accept.

    As to compatibility ...

    I think that's something we just have to accept as impossible to achieve. As soon as something is added and used by a programmer which PropTool doesn't support compatibility is broken. The extent of compatibility should be to using existing code without needing change to work. If someone wants to use code which requires a third party compiler with the PropTool then that's unfortunate, it may not be possible.

    Not a perfect situation but the best there is. If PropTool did all that was necessary there would be little incentive to create alternatives. Except to duplicate it as open source on a point of principle, there would be no reason to go beyond replicating functionality.

    If PropTool were open source in some manner then I expect effort would have gone into improving PropTool to do what was required. As it isn't, the only alternative is parallel development and divergence from PropTool functionality.

    I'd go as far as saying third party tools shouldn't hold themselves back to remain PropTool compatible but that PropTool ( by which I mainly mean the compiler ) needs to pull itself forward to achieve what third party tools can offer and be compatible with them. I appreciate that Parallax don't have the resources individuals can throw at tool development, so they have to make the decision; provide those resources to stop Spin development tool fragmentation, open the tool up so third parties can develop PropTool itself rather than competing tools, or accept the fragmentation.

    There are ways to open up PropTool without going fully Open Source or losing copyright or control and I'd like to see that happen. Done right they will get free resources from developers who end up contributing ( to the benefit of everyone ) rather than seeing the fragmentation as now which does give rise to legitimate concerns over compatibility. Not just with PropTool but between third party tools.

    The genie is out the bottle and without a single direction of focus ( which PropTool itself could provide as the de-facto tool ) people will go in whatever direction they want to and fragmentation will get worse. If that's the situation we just have to accept it.
  • dMajodMajo Posts: 851
    edited 2008-10-04 13:24
    Praxis said...
    @BradC: Be that as it may then please suggest how to do code folding without something to indicate the end of a block?
    I am new to Propeller but VS old user so I hope I have understand what you mean. What about using yours key words but enclused in brackets
    eg. {#END REGION}, {#ENDSUB}

    This do not alter the spin syntax and mantain compatibility with PropTool

    regards
    Dario

    Post Edited (dMajo) : 10/4/2008 1:31:10 PM GMT
  • mparkmpark Posts: 1,266
    edited 2008-10-06 09:18
    Version 0.19 in first post.
    My attempt to add multidimensional arrays to Spin. Only works with VARs. Syntax is C-style:
    con
    _clkmode = xtal1+pll16x
    _xinfreq = 6_000_000
    obj
    text : "tv_text"
     
    var
      long array[noparse][[/noparse]10][noparse][[/noparse]10]          ' 10 x 10 matrix
      
    pub main | i, j, k
      text.start(24)     
      k := 0
      repeat i from 0 to 9        ' initialize array
        repeat j from 0 to 9
          array[noparse][[/noparse]i][noparse][[/noparse]j] := k++
    
      repeat i from 0 to 9        ' print array
        repeat j from 0 to 9
          text.dec( array[noparse][[/noparse]i][noparse][[/noparse]j] )
          text.out( " " )
        text.out( 13 ) ' CR
          
    

    No limit on number of dimensions. No bounds-checking.

    I added this for myself (I'm thinking of writing a program where this might come in handy), but I wonder, does anyone else find this useful?
    ·
  • hippyhippy Posts: 1,981
    edited 2008-10-06 09:55
    There's a potential for confusion between the way arrays are used here ( myArray[noparse]/noparse[noparse]/noparse ) and the way the current indexing works and with long[noparse]/noparse[noparse]/noparse etc, and particularly if passing a pointer to a multi-dimensioned array into a method.

    It may be better to use comma separated indexing.
  • mparkmpark Posts: 1,266
    edited 2008-10-06 15:48
    Good point!
  • rokickirokicki Posts: 1,000
    edited 2008-10-06 17:52
    If your compiler accepts non-SPIN input, at least give an option to generate exact-SPIN *output*.
    This way, if people want to program in SpinX or Pascal or BASIC or whatnot, they would still
    be able to generate PropTool-compatible Spin programs.
  • mparkmpark Posts: 1,266
    edited 2008-10-06 22:45
    Well, some non-Spin constructs do not have a Spin counterpart.

    Anyhoo, I've updated the first post with version 0.20: array syntax is now a[noparse][[/noparse]i,j,k].
  • BradCBradC Posts: 2,601
    edited 2008-10-07 08:11
    mpark said...
    Well, some non-Spin constructs do not have a Spin counterpart.

    Anyhoo, I've updated the first post with version 0.20: array syntax is now a[noparse][[/noparse]i,j,k].

    Heya! That's a really neat implementation. I like the way you did that.

    Now I gotta think about "Keeping up with the Joneses" .. so much to do, so little time.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • simonlsimonl Posts: 866
    edited 2008-10-07 11:37
    Excellent work mpark. I haven't tried your compiler yet, but I just know it's going to be something I make a lot of use of in the future, so well done.

    BTW: Any idea if this is going to fit with Praxis' IDE?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Cheers,
    Simon

    www.norfolkhelicopterclub.com

    You'll always have as many take-offs as landings, the trick is to be sure you can take-off again wink.gif
    BTW: I type as I'm thinking, so please don't take any offence at my writing style smile.gif
  • Mike GreenMike Green Posts: 23,101
    edited 2008-10-09 16:11
    I've been trying homespun under mono and the MacOS and have run into problems with the command line scanning. The MacOS provides for conversion of file names into POSIX format with quotes around them and these use "/" for subdirectory delimiters. Homespun chokes on them thinking they're some kind of unknown option. Specifically, the command line is:

    mono /Applications/MonoApps/homespun.exe -L '/Applications/MonoApps/PropLib/' '/Users/mgreen/Desktop/PodiumPiece/PodiumTest.spin'

    The error message I get is:

    Unknown option: /Applications/MonoApps/PropLib/
    Unknown option: /Users/mgreen/Desktop/PodiumPiece/PodiumTest.spin
    No input file specified

    I could convert the "/" to "\", but the use of "/" is a standard (POSIX) and it would be nice to be able to accomodate it.
  • BradCBradC Posts: 2,601
    edited 2008-10-09 16:46
    Mike Green said...
    I've been trying homespun under mono and the MacOS and have run into problems with the command line scanning. The MacOS provides for conversion of file names into POSIX format with quotes around them and these use "/" for subdirectory delimiters. Homespun chokes on them thinking they're some kind of unknown option. Specifically, the command line is:

    mono /Applications/MonoApps/homespun.exe -L '/Applications/MonoApps/PropLib/' '/Users/mgreen/Desktop/PodiumPiece/PodiumTest.spin'

    I'm not sure about the implementation on OSX, but on Linux I could not get it to compile anything that was not in the immediate directory.

    brad@bklaptop2:~$ mono homespun018.exe /tracks/Objects/FemtoBasic_2008-02-28/FemtoBasic/FemtoBasic.spin
    Homespun Spin Compiler 0.18
    Unknown option: /tracks/Objects/FemtoBasic_2008-02-28/FemtoBasic/FemtoBasic.spin
    No input file specified

    brad@bklaptop2:/tracks/Objects/FemtoBasic_2008-02-28/FemtoBasic$ mono ~/homespun018.exe FemtoBasic.spin Homespun Spin Compiler 0.18
    parsing FemtoBasic.spin
    parsing fsrwFemto.spin
    parsing sdspiFemto.spin
    parsing vga_Drive.spin
    parsing comboKeyboard.spin

    The other issue I have is with the libraries and a case sensitive filesystem, but I don't think that is an issue on OSX.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • mparkmpark Posts: 1,266
    edited 2008-10-09 17:04
    Couple of things.
    At the moment, Homespun expects the -L to be followed *immediately* by the directory (no intervening spaces). Also, each directory needs its own -L.
    What this means for quoted directories, I don't know. Do you have to include the -L inside the quotes? Beats me. I will change the -L so that it no longer expects to be conjoined with the directory, but for now you'll have to experiment.

    The other thing is that Homespun expects - and / to preface options. Of course if your source file starts with / then it gets confused, but who the heck uses / in paths? (Note to self: non-Windows people, you dum-dum.)
    I guess the easiest thing to do is to take out the slash options, except I like using slash <pout>. I guess I could treat any unrecognized option as a filename. Nah, I'll take out slash.

    Oh, and Simon, you'd have to ask Praxis.
  • SapiehaSapieha Posts: 2,964
    edited 2008-10-09 17:15
    Hi mpark.
    I am XP user but if You use \ and / as path options .
    Use - as Directive options.
    That give both worlds XP, OSX and Linux posiblites tu take correct path

    Ps. It is not problem for XP environment.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • PraxisPraxis Posts: 333
    edited 2008-10-10 08:43
    For the listing output can you single quote the beginning of the comment lines i.e.

    '*******************************************************************************
    '                                   test.spin                                    
    '*******************************************************************************
    
    '==================================== CONs =====================================
    
    '============================ Method #1: PUB START =============================
    'PUB START (DEBUG_RX, DEBUG_TX)
    '-------------------------------------------------------------------------------
    
    
    '================================= VAR Section =================================
    0ba4: 00 00 00 00                  ' LONG S
    0ba8: 00 00 00 00                  ' LONG MS
    0bac: 00 00 00 00                  ' LONG US
    0bb0: 00 00 00 00                  ' LONG LAST_FREQ
    0bb4: 00 00 00 00                  ' LONG LAST_FREQB
    0bb8: 00 00 00 00 00 00 00 00 ' BYTE DATAIN(50)
    0bc0: 00 00 00 00 00 00 00 00 ' 
    0bc8: 00 00 00 00 00 00 00 00 ' 
    0bd0: 00 00 00 00 00 00 00 00 ' 
    0bd8: 00 00 00 00 00 00 00 00 ' 
    0be0: 00 00 00 00 00 00 00 00 ' 
    0be8: 00 00                          '
    0bea: 00                              ' BYTE DEBUG_PIN
    0beb: 00                              ' BYTE DEBUGIN_PIN
    
    
  • PraxisPraxis Posts: 333
    edited 2008-10-10 10:10
    Hi just a few questions:

    1. Is the .out appended to the filename on the compile code required, if not can it be dropped?
    2. Will you be providing a compile to binary output?
    3. Can you have a switch to suppress the parsing & compiling messages i.e.

    -ix or /ix where x = 1 show parse, 2 show compile and 3 show all.

    All errors and warnings (with /w) display as normal.

    4. Can you have an (optional) destination (and or filename) for the compiled output?

    Post Edited (Praxis) : 10/10/2008 10:16:25 AM GMT
  • mparkmpark Posts: 1,266
    edited 2008-10-10 10:29
    Hi Praxis!
    I think single quotes are possible, but why? Where are you going with this?

    I can certainly drop the .out; it was just there so I could tell Homespun output from Proptool output.

    I could make .binary files (now that I know what they are, from another thread).

    I can add a -ix switch, but I think I'll eliminate the "compiling blah" messages altogether; they don't really add any information. Why do you suggest "i" for this switch?
  • PraxisPraxis Posts: 333
    edited 2008-10-10 11:21
    The single quote for the listing file comments is so that when I pull the listing file into the IDE I can colorize it.

    As for "i" short for information.

    Keep the compiling messages as I can optional pull them into the IDE, its an nice check that all the modules compiled and provides feedback that compiling is functioning OK, its the parsing messages that are not really required but can be retained with a switch option for debug etc.

    Just a thought for standardization:

    A warning message is in the format - Warning: MATHFLOAT32A.spin (91, 29): ORG without address (defaults to 0)

    Whereas an error message (parser) is - CompilerTest.spin (15, 8): Unexpected LONG1

    Can we get the error message in this format - Error: CompilerTest.spin (15, 8): Unexpected LONG1

    In the IDE these messages will be displayed back to the user and a double click on the displayed message will open (if already not) the code document and show the error.

    Cheers

    Post Edited (Praxis) : 10/10/2008 11:52:22 AM GMT
  • PraxisPraxis Posts: 333
    edited 2008-10-10 13:59
    Can you give me a list of all the possible error/warning outputs such as "Unexpected" etc that your compiler will output.

    Thanks
  • SapiehaSapieha Posts: 2,964
    edited 2008-10-10 14:57
    Hi Praxis.

    I have one quwstion if You can have alternate listing In Pasm section.

    Example....
    0ba4: 00 00 00 00
    0ba4: EE1|FF1|1110|1111|02 It is more reliable in debuging to fould code and what is doing on Registers in COG < .............. (000011 000i 1111 ddddddddd sssssssss)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • Cluso99Cluso99 Posts: 18,063
    edited 2008-10-11 03:28
    If you decide to allow an alternate pasm listing as Sapieha has suggested, put in on the line as well, but in correct order
    Example:
    0BA4: 00 00 00 00 >1FF 1F 1FF 1FF .........
    0BA4: 00 00 00 00 >1FF 1F 1FF #1FF ......... (# for immediate would be even better)


    format 1FF = opcode, 1F = Immediate+cond, 1FF = Dest, 1FF = Source

    It's a partway towards disassembly.
  • SapiehaSapieha Posts: 2,964
    edited 2008-10-11 05:48
    Hi Cluso99.

    For me is is not marter with order is native else goes backwards.
    My idea was to fllow after bytes in COG list.
    It gives easy comparation with Instructions in Propeller Manual.

    Example....
    0ba4: 11 22 33 44
    .......................flags as bits
    0ba4: 1AA|1BB|1110|1111|1C

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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

    Post Edited (Sapieha) : 10/11/2008 5:55:55 AM GMT
  • mparkmpark Posts: 1,266
    edited 2008-10-11 07:01
    Version 0.21 in first post. Mostly minor changes.

    Experimental new feature: object sharing. Suppose you have an object, top, that has a child object, middle, that in turn has a child, bottom. Suppose in addition that each object will be using float32, floatString,·and tv_text. Now check this out:
    ' top.spin
    con
    _clkmode = xtal1+pll16x
    _xinfreq = 6_000_000
    obj
      middle : "middle"
      text   : "tv_text" pointer
      f      : "float32" pointer
      fp     : "floatString" pointer
    pub Main
      middle.Start
      text := middle.PointerToTvText
      f := middle.PointerToFloat32
      fp := middle.PointerToFloatString
      text.str( string( "top says sqrt(33) = " ) )
      text.str( fp.FloatToString( f.FSqr( 33.0 ) ) )
      text.out( 13 )
    
    

    ' middle.spin
    obj
    text   : "tv_text"
    f      : "float32"
    fp     : "floatstring"
    bottom : "bottom"
    pub Start
      text.start(24)
      f.start
      bottom.Start( text, f, fp )
      text.str( string( "middle says sqrt(22) = " ) )
      text.str( fp.FloatToString( f.FSqr( 22.0 ) ) )
      text.out( 13 )
    pub PointerToTvText
      return text
    pub PointerToFloat32
      return f
    pub PointerToFloatString
      return fp
    
    

    ' bottom.spin
    obj
      text : "tv_text" pointer
      f    : "float32" pointer
      fp   : "floatString" pointer
    var
      byte testbyte
    pub Start( pText, pF, pFp )
      text := pText
      f := pF
      fp := pFp
      text.str( string( "bottom says sqrt(11) = " ) )
      text.str( fp.FloatToString( f.FSqr( 11.0 ) ) )
      text.out( 13 )
    
    

    Note that only middle has an actual tv_text object. It passes a "pointer to tv_text"·up to top and down to bottom. In other words, top, middle, and bottom are all using one "instance" of tv_text (and the same for float32 and floatString).

    I haven't tested this extensively, but the above program does work.

    Note that this runs into trouble if, for example, middle contains an array of bottom objects. middle can share its tv_text etc with only one bottom at a time. That is, if middle calls bottom[noparse][[/noparse]0].Start(text, f, fp), only bottom[noparse][[/noparse]0] can use the tv_text object. bottom[noparse][[/noparse]1] and bottom[noparse][[/noparse]2] are out of luck. Ten points if you can figure out why. A thousand points if you can figure out a way around it.
Sign In or Register to comment.