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

Homespun Spin compiler 0.31: Now open source

16781012

Comments

  • mparkmpark Posts: 1,305
    edited 2010-11-28 18:27
    jazzed wrote: »
    Michael (mpark),

    I hope you had a happy thanksgiving.

    Same to you, Steve. I will take a look at the Homespun source (it's been a while) to see what I might be able to do. No promises beyond that.
  • jazzedjazzed Posts: 11,803
    edited 2010-11-28 21:54
    mpark wrote: »
    Same to you, Steve. I will take a look at the Homespun source (it's been a while) to see what I might be able to do. No promises beyond that.
    Thanks Michael. Having #include built-in with Homespun and BSTC would allow much flexibility. I guess it is practical to use an external CPP for users who need it. Even some of the advanced users here don't get it though (and are bias blind).

    BTW, I used Reflector to look at your code and it's interesting that you use a different class for each bytecode. That's a good way to do it with IDL though. The only thing that stops me from recompiling is some invisible methods you're using that seem to be associated with Hashtable.
  • mparkmpark Posts: 1,305
    edited 2010-11-29 02:56
    Rename attached file to .exe and try
    #include "filename"
    
    in a Spin file.

    N.B.: This is an experimental version of Homespun. Download only if you want to test early #include functionality.

    Edit: Removed 0.27x; see 0.27y a few posts down.
  • jazzedjazzed Posts: 11,803
    edited 2010-11-29 09:01
    mpark wrote: »
    Rename attached file to .exe ....
    Michael, thank you very much for putting time into this.

    That seems to work fine for a simple program. It even adds PASM code to the .lst file where the #include statement is added. Perfect :D

    I did run into one annoying factor though which I believe I've seen before. If I #define DSYMBOL in one spin file that uses other spin objects, DSYMBOL doesn't seem to be passed to other files ... see example below which fails. Is it possible to pass the DSYMBOL down to the other objects?
    ' begin testinc.spin
    
    #define USE_PASM
    
    OBJ x : "testobj"
    
    PUB main
        x.start
        repeat
    
    ' begin testobj.spin
    
    PUB start
        cognew(@entry,0)
    
    #include "pasm.spin"
        
    ' begin pasm.spin
    
    #ifdef USE_PASM
    dat     org
    entry
            mov     dira,#0
            jmp     #entry
    #endif
    
    

    Just one more thing while you're thinking about this (sorry if I ask too much). Is it possible to allow a -D list of arguments to the homespun command line to use for compiling?

    Thanks a ton!

    --Steve
  • mparkmpark Posts: 1,305
    edited 2010-11-29 10:02
    jazzed wrote: »
    I did run into one annoying factor though which I believe I've seen before. If I #define DSYMBOL in one spin file that uses other spin objects, DSYMBOL doesn't seem to be passed to other files

    Right, that's the issue Cluso mentioned a few posts ago. One step at a time.
  • mparkmpark Posts: 1,305
    edited 2010-11-29 23:51
    Attached is version 0.27y (rename to .exe). This one should pass #defined symbols down to sub-objects. You can also define symbols on the command line with -D <symbol> (e.g. homespun027y blah.spin -D DEBUG -D LMM). Note that option -d (lower-case) does something else (generates listing file).

    This is an experimental version of Homespun. Download only if you want to test the new #define functionality. Find bugs soon, while I'm still thinking about the code.

    Edit: Removed attachment.
  • RossHRossH Posts: 5,454
    edited 2010-11-30 00:00
    Hi Michael,

    Thanks for all your work - I may not have time to incorporate this into the next version of Catalina, but it will certainly go in the one after that!

    Ross.
  • jazzedjazzed Posts: 11,803
    edited 2010-11-30 00:15
    mpark wrote: »
    This is an experimental version of Homespun. Download only if you want to test the new #define functionality. Find bugs soon, while I'm still thinking about the code.
    Looking good so far. I see lots of defines popping up in the compiler output in various sources. More testing tomorrow ....
  • mparkmpark Posts: 1,305
    edited 2010-11-30 00:19
    Hi Ross,

    Wait for 0.28 to incorporate into Catalina. Who knows if these experimental versions really work. I've only done powderpuff testing. I expect bug reports.


    m
  • jazzedjazzed Posts: 11,803
    edited 2010-11-30 09:02
    Hi Michael.

    I thought I would try replacing BSTC for some projects since BSTC does not have the #include feature.

    I'm having an issue with libraries running with mono.net. My libraries are in /home/user/spin

    Should this work?

    mono /home/steve/bin/homespun027y.exe spinfile.spin -b -L /home/user/spin

    If I copy the library file to the working folder, everything works fine.

    Thanks.
    --Steve
  • mparkmpark Posts: 1,305
    edited 2010-11-30 11:10
    jazzed wrote: »
    Should this work?

    mono /home/steve/bin/homespun027y.exe spinfile.spin -b -L /home/user/spin

    At the moment, #include looks for files only in the working directory (unless the filename includes a path); could that be what's wrong?
  • jazzedjazzed Posts: 11,803
    edited 2010-11-30 11:59
    mpark wrote: »
    At the moment, #include looks for files only in the working directory (unless the filename includes a path); could that be what's wrong?

    The compiler is not able to find an OBJ file in my specified library path.
    The problem I see is not related to #include.
  • mparkmpark Posts: 1,305
    edited 2010-11-30 12:53
    Oh wait! Try
    mono /home/steve/bin/homespun027y.exe spinfile.spin -b -L /home/user/spin/
    
    (note final /)

    Edit: Never mind. I thought we could fake it out, but it looks like I have to make a fix (for / vs \). Guh. New version coming soon.
  • mparkmpark Posts: 1,305
    edited 2010-11-30 15:49
    New version attached.

    This one should understand Windows-style paths (\) and non-Windows (/) for the SPINLIB environment variable and -L command-line option. To increase your chances for success, add the appropriate separator at the end:
    -L \foo\blah\ or -L /foo/blah/

    New in this version: FILE and #INCLUDE directives will search libraries if the file isn't in the current directory.

    Also new: TESTN instruction added (thanks, Hanno!).

    Edit: Removed attachment.
  • jazzedjazzed Posts: 11,803
    edited 2010-11-30 16:28
    mpark wrote: »
    New version attached.


    Yay! :D
    $ mono homespun027z.exe con.spin -b -L ~/spin
    Homespun Spin Compiler 0.27z
    parsing con.spin
    parsing /home/steve/spin/FullDuplexSingleton.spin
    compiling con.spin
    compiling FullDuplexSingleton.spin
    writing con.binary
    

    And a more complicated example ....
    Homespun Spin Compiler 0.27z
    parsing debug_zog.spin
    parsing /home/steve/spin/userdefs.spin
    parsing zog.spin
    parsing SdramCache.spin
    parsing FullDuplexSerialPlus.spin
    parsing ZogInfo.spin
    parsing memory.spin
    parsing fsrwFemto_rr001.spin
    parsing sdspiFemto.spin
    compiling debug_zog.spin
    compiling userdefs.spin
    compiling zog.spin
    compiling FullDuplexSerialPlus.spin
    compiling ZogInfo.spin
    compiling memory.spin
    compiling fsrwFemto_rr001.spin
    compiling sdspiFemto.spin
    compiling SdramCache.spin
    writing debug_zog.binary
    

    :D

    If there was any one wish left to be granted, I would wish for Homespun to print the final image binary size before writing the file.
  • HannoHanno Posts: 1,130
    edited 2010-11-30 16:45
    Thanks Michael for this excellent compiler!
    The latest betas of ViewPort and 12Blocks now use HomeSpun to compile spin code. To date I'm only taking advantage of HomeSpun's support for multiple libraries. I'm very excited about conditional compilation and include.
    Hanno
  • mparkmpark Posts: 1,305
    edited 2010-11-30 18:16
    jazzed wrote: »
    If there was any one wish left to be granted, I would wish for Homespun to print the final image binary size before writing the file.

    It currently says "writing blah.binary" at the end; you want it to say "writing 108 bytes to blah.binary"?
  • jazzedjazzed Posts: 11,803
    edited 2010-11-30 18:27
    mpark wrote: »
    It currently says "writing blah.binary" at the end; you want it to say "writing 108 bytes to blah.binary"?
    Yes, thank you very much.

    Knowing how close I am to using 32768 bytes for normal size programs is of great benefit. It also helps identify other issues during development.
  • mparkmpark Posts: 1,305
    edited 2010-11-30 23:54
    All right, after exhaustive testing <yeah, right> I've posted version 0.28 at the top of this thread. The only change from 0.27z is jazzed's last request and the version number.

    I kinda feel I should apologize for taking soooo long to add #include. People have been requesting it for a long time. I avoided it because I thought it would be very difficult, given Homespun's design (or lack thereof). It turned out to be not that hard (I think the fact that I hadn't looked at the code in months gave me a little distance to see a solution), so thanks for that last push, Steve!

    Anyway, it seems to be working, so have at it.
  • Cluso99Cluso99 Posts: 18,069
    edited 2010-12-01 03:38
    michael: Congratulations. Include is a well sort after extra.
  • Heater.Heater. Posts: 21,230
    edited 2010-12-01 07:50
    Excellent.

    Is it possible for HomeSpun emit just the compiled DAT section of a Spin file as a binary blob without any of the spin stuff in it?
  • mparkmpark Posts: 1,305
    edited 2010-12-01 10:35
    Heater. wrote: »
    Is it possible for HomeSpun emit just the compiled DAT section of a Spin file as a binary blob without any of the spin stuff in it?

    I suppose so. What should happen in the case of sub-OBJs, when there'll be multiple, non-contiguous DAT sections? Write just the first, write them all, error out, or something else?
  • SapiehaSapieha Posts: 2,964
    edited 2010-12-01 10:52
    Hi mpark.

    If possible write every DAT section that has ORG 0 as separate file.
    Second possibility Write every section as next 2k boundary in same file.


    mpark wrote: »
    I suppose so. What should happen in the case of sub-OBJs, when there'll be multiple, non-contiguous DAT sections? Write just the first, write them all, error out, or something else?
  • mparkmpark Posts: 1,305
    edited 2010-12-17 02:35
    Thanks Sapieha, those are good ideas. However, I decided to follow BST's lead and just write the DAT of the top object. As of version 0.29, you can invoke Homespun with -c on the command line to write the DAT section to filename.dat.

    Version 0.29 attached to top post.
  • Heater.Heater. Posts: 21,230
    edited 2010-12-17 02:58
    mpark,

    Sorry, I seem to have missed your question re: emitting DAT multiple sections.

    I think your solution and BST's is perfectly acceptable. i.e. Just ignore the problem and write out the first DAT section you come across.

    I suspect that the vast majority of objects follow a simple model of: some spin code to get a cog started plus access methods thereafter, plus a single DAT section for the work to be done in a COG.

    For sure if anyone comes up with at more complicated case they actually want to extract for use with C or whatever they will soon let you know:)

    Looks like this will make the ZOG interpreter much more manageable, given all the different external memory platforms it must support.

    Also looks like Jazzed is on that case already:)
  • jazzedjazzed Posts: 11,803
    edited 2010-12-17 07:48
    Michael.

    This is a good feature. I can almost completely replace BSTC with Homespun in ZOG now.

    There is one problem though. As you can see the binaries endian orders are different. It would be nice if they were the same. There are ways around this with the superior GNU make, but not others. Just one idea: you could have -C for big endian -vs- -c which now produces little endian.
    $ od -Ax -tx1 TV.dat.homespun 
    000000 5c 2a fe a0 0a 36 fe a0 15 2d be 5c 02 36 fe e4
    000010 5c 2a fe a0 01 6a 7e 61 fc f6 8d a0 02 6a 7e 62
    ...
    $ od -Ax -tx1 TV.dat.bstc 
    000000 a0 fe 2a 5c a0 fe 36 0a 5c be 2d 15 e4 fe 36 02
    000010 a0 fe 2a 5c 61 7e 6a 01 a0 8d f6 fc 62 7e 6a 02
    ...
    

    BTW: Would you consider adding the common "#ifndef symbol" syntax ?

    Thanks for your efforts.
    --Steve
  • mparkmpark Posts: 1,305
    edited 2010-12-17 10:37
    BSTC is writing out big-endian?? That doesn't sound right, and I can't repro it here. My copy of BSTC is pretty old, though (0.14)... but big endian just doesn't make sense.
  • jazzedjazzed Posts: 11,803
    edited 2010-12-17 10:57
    mpark wrote: »
    BSTC is writing out big-endian?? That doesn't sound right, and I can't repro it here. My copy of BSTC is pretty old, though (0.14)... but big endian just doesn't make sense.
    I'm sorry. You're right: just using bstc.linux -c produces the right order. The dump I had was from a file apparently and unexpectedly manipulated by the objcopy program. For some reason the ZOG library makefile objcopy command is swapping binary source bytes. ....

    Almost home :D Merry Christmas.
  • mparkmpark Posts: 1,305
    edited 2010-12-17 11:10
    Well that's a relief. I'll look into #ifndef next.
  • mparkmpark Posts: 1,305
    edited 2010-12-17 14:30
    Version 0.30 in top post. Added #ifndef.

    I just copied the #ifdef code and changed the sense of a test. That should work, right?
Sign In or Register to comment.