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

Homespun Spin compiler 0.31: Now open source

1235712

Comments

  • Cluso99Cluso99 Posts: 18,063
    edited 2008-09-19 17:57
    Michael, "&" is fine by me. Just having something to do this is all I need. smile.gif
  • Mike GreenMike Green Posts: 23,101
    edited 2008-09-19 18:13
    "&" is used for logical and.
  • mparkmpark Posts: 1,258
    edited 2008-09-19 18:25
    Yes, and in C, it is bitwise-AND. But those are when it's a binary operator. As a unary operator we can make it do something else. Assuming I can get my parser to cooperate.

    It was just a thought anyway. Non-C people might be more confused by & than by @@@. I know I used to think & was an odd choice for address-of.

    Anyone have suggestions for alternatives to @@@?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Michael Park

    PS, BTW, and FYI:
    To search the forum, use search.parallax.com (do not use the Search button).
    Check out the Propeller Wiki: propeller.wikispaces.com/
  • heaterheater Posts: 3,370
    edited 2008-09-19 18:40
    "Anyone have suggestions for alternatives to @@@?"

    Yep. On my Finnish keyboard shift-4 produces a symbol that looks like some kind of rocket coming straight at me.
    It is this ¤

    I don't even remember now if that exists on "normal" USA/UK keyboards.

    Thing is it really looks like it's telling me that something is "at" this point. Perhaps you could be the first to create any kind of language compiler that uses that symbol.

    Does anyone know what that symbol is called and/or what it is actually supposed to mean?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • SapiehaSapieha Posts: 2,964
    edited 2008-09-19 18:51
    Hi heater

    In Swidish it is called a Sun (solen).

    and if I remember it first come in ABC80 Swedish 8 Bit Z80 based computer.

    Ps. Talar du svenska?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nothing is impossible, there are only different degrees of difficulty.
    For every stupid question there is at least one intelligent answer
    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/19/2008 7:00:44 PM GMT
  • heaterheater Posts: 3,370
    edited 2008-09-19 19:09
    Thanks Sapieha. Interesting.

    Sounds perfect for the job at hand, but I don't know if those outside Scandinavia can generate it easily.

    I'm actually English but I've been camped out here in Helsinki for some years and never found anyone who could tell me what that ¤ is. No svenska sadly and my Finnish is still "ei hyvä"

    Any other Propeller users in Helsinki or around out there ?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • SapiehaSapieha Posts: 2,964
    edited 2008-09-19 21:57
    Hi mpark.

    I have one question on /d.

    In End of it Can You ad memory usage else after every obiect.
    With to Big program....
    Maybe compile that in adress range to big for Prop > 32Kb and generate Labels adresses But Not generate Binary image.


    Example...

    compiling altair_sim.spin
    XXX Longs
    compiling altair_cpu.spin
    XXX Longs
    compiling altair_mem.spin
    XXX Longs
    compiling altair_ios.spin
    XXX Longs
    compiling sdspiqasm.spin
    XXX Longs
    compiling PC_Keyboard.spin
    XXX Longs
    compiling VGA_Text.spin
    XXX Longs
    compiling vga.spin
    XXX Longs
    Too big by 150 longs

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nothing is impossible, there are only different degrees of difficulty.
    For every stupid question there is at least one intelligent answer
    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
  • AribaAriba Posts: 2,591
    edited 2008-09-19 23:42
    How about @| instead of @@@? This means "Absolut address of" for me. The parser should not have a problem to separate it from an OR.

    Andy
  • mparkmpark Posts: 1,258
    edited 2008-09-20 00:50
    Hmmm, no solen on my keyboard. Sorry.

    Sapieha, I think I can add that.

    Ariba, if we're going to do that, maybe we should use the Spin absolute value operator: @|| or ||@
    Or heck, we could use math notation: |@|

    Well, let's see if a consensus emerges. @@@ isn't that bad.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Michael Park

    PS, BTW, and FYI:
    To search the forum, use search.parallax.com (do not use the Search button).
    Check out the Propeller Wiki: propeller.wikispaces.com/
  • SapiehaSapieha Posts: 2,964
    edited 2008-09-20 00:56
    Hi mpark

    Thanks.

    It can be very handy to optimize objects to Fit in memory.
    Not in al circumstances objects must have al PRI routines. And that can help to find them.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nothing is impossible, there are only different degrees of difficulty.
    For every stupid question there is at least one intelligent answer
    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/20/2008 1:02:49 AM GMT
  • Cluso99Cluso99 Posts: 18,063
    edited 2008-09-20 02:42
    Since @@Label is invalid in pasm, I wonder if this is any use??

    In fact, the line in spin
    x := long[noparse][[/noparse]@Label]
    gives the correct data if
    DAT
    Label mov x,y

    but
    DAT
    xyz wrlong zzz,@Label
    does not unless you use
    xyz wrlong zzz,(@Label+$10)
    and the $10 may vary???

    so maybe we could do
    DAT
    xyz wrlong zzz,@@Label

    Any comments??
    PS Iam grateful for anything that works smile.gif
  • BradCBradC Posts: 2,601
    edited 2008-09-20 04:48
    I don't like @@@, but then at least it's an invalid operator in the Parallax compiler.
    I like it more than the alternatives [noparse]:)[/noparse]

    Using & would likely get confusing.

    @@@ is ugly, but unique. Why not stick with it.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • BradCBradC Posts: 2,601
    edited 2008-09-20 05:14
    Cluso99 said...
    Since @@Label is invalid in pasm, I wonder if this is any use??

    In fact, the line in spin
    x := long[noparse][[/noparse]@Label]
    gives the correct data if
    DAT
    Label mov x,y

    but
    DAT
    xyz wrlong zzz,@Label
    does not unless you use
    xyz wrlong zzz,(@Label+$10)
    and the $10 may vary???

    so maybe we could do
    DAT
    xyz wrlong zzz,@@Label

    Any comments??
    PS Iam grateful for anything that works smile.gif

    That is an interesting thought. Of course @@ works in Spin, as the interpreter does it for you. Perhaps just making @@ work in PASM as a constant and leaving the spin operator as is would do the job ?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • BradCBradC Posts: 2,601
    edited 2008-09-20 08:26
    I thought I'd run my regression test on homespun to see if anything else in the obex crashed it out, but there is no option to specify the library search dir like Propellent has.

    Is that something you are possibly investigating adding? At the moment I can't compile about 90% of the files as they reference something in the Parallax standard library and homespun can't find them.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • OwenSOwenS Posts: 173
    edited 2008-09-20 08:46
    I'd vote for the unary & operator, since that makes most sense to me (as a C programmer)

    (It should be implementable with similar code to the unary - operator as well)
  • hippyhippy Posts: 1,981
    edited 2008-09-20 12:21
    I'd vote for &, but @@ has an appeal. @@@ I could live with. I think @| etc are just going to be difficult to remember.
  • BradCBradC Posts: 2,601
    edited 2008-09-20 12:32
    hippy said...
    I'd vote for &, but @@ has an appeal. @@@ I could live with. I think @| etc are just going to be difficult to remember.

    As long as you don't need the constant in a spin block..
    ie..
    PUB AAA | J[noparse][[/noparse]@@@fred]

    .. and that'd be a very odd use, then I reckon @@ makes the most sense as it retains logical compatibility with the runtime behavior in Spin.

    I just think using & is likely to get confusing for newbies if they do something dumb and the compiler does not kick and scream..

    DAT
    i long 123
    aaaa long i & j
    mov i, &j

    I can just see potential for confusion when the code refuses to do what is expected of it because the operator has been used as a unary instead of binary (or vice versa).
    At least with @@ it's less likely to happen, and the behaviour in DAT will be effectively identical to the behaviour in Spin.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • mparkmpark Posts: 1,258
    edited 2008-09-20 14:09
    BradC said...
    I thought I'd run my regression test on homespun to see if anything else in the obex crashed it out, but there is no option to specify the library search dir like Propellent has.

    Is that something you are possibly investigating adding?

    Yes, for sure. I was thinking environment variable rather than compiler option, but whatever. Do people have a preference?

    I like what you were saying in another thread about multiple search directories and doing away with the "full pathname" incompatibility. I think that's definitely the way to go.
  • mparkmpark Posts: 1,258
    edited 2008-09-20 14:12
    OwenS said...
    I'd vote for the unary & operator, since that makes most sense to me (as a C programmer)

    (It should be implementable with similar code to the unary - operator as well)

    Hi Owen,

    In your assembler you use @ to mean what we're calling @@@. Did you ever consider using & instead of @?
  • BradCBradC Posts: 2,601
    edited 2008-09-20 14:31
    mpark said...
    BradC said...
    I thought I'd run my regression test on homespun to see if anything else in the obex crashed it out, but there is no option to specify the library search dir like Propellent has.

    Is that something you are possibly investigating adding?

    Yes, for sure. I was thinking environment variable rather than compiler option, but whatever. Do people have a preference?

    I like what you were saying in another thread about multiple search directories and doing away with the "full pathname" incompatibility. I think that's definitely the way to go.

    My preference is for a command line option. Environment variables are rarely properly portable across operating systems. In addition a command line option makes it easier for those that want to script the compiler into an IDE.

    On another note, I've managed to duplicate your @@@ behaviour in my compiler. Because I'm a terrible programmer and an awful software architect it took a lot of massaging to make it work! I dunno how many LOC you have in Homespun, but I've cracked 9.2k here now..

    My automated regression test compiles nearly 800 spin files at the moment. If you can get a library path option in there I can run homespun against the same set of files..

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • mparkmpark Posts: 1,258
    edited 2008-09-20 15:13
    Good points, Brad.

    If you want to talk about bad code and architecture, I think Homespun will give you a run for your money. There's a reason I'm not sharing source code!

    What does your library path option look like? Something along these lines? /lib dir1;dir2;dir3
    (I don't know if that's even legal; maybe it needs quotes.)
  • BradCBradC Posts: 2,601
    edited 2008-09-20 15:21
    mpark said...
    Good points, Brad.

    If you want to talk about bad code and architecture, I think Homespun will give you a run for your money. There's a reason I'm not sharing source code!

    I'm a pretty horrid architect. I've had to re-write the code generator twice after painting myself into a corner. But then I've never written a tokeniser/parser before either.
    I dunno how you implemented the @@@ operator, but I ended up completely sequentially re-compiling my DAT and SPIN blocks until they stop moving about as the PBASE on each object changes. It's ugly but it works.
    mpark said...


    What does your library path option look like? Something along these lines? /lib dir1;dir2;dir3
    (I don't know if that's even legal; maybe it needs quotes.)

    Yeah, I've not fleshed out the lib path on Windows yet.. but my linux and MacOS paths are separated with colons.

    /home/brad/lib1:/opt/ParallaxLib:/tmp/lib
    Which is perfectly legal on Linux..

    I guess it'd have to be ';' on Windows. I've got a long flight coming up in a fortnight, so I'll have plenty of time to play with windows oddities.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • OwenSOwenS Posts: 173
    edited 2008-09-20 15:43
    mpark said...
    OwenS said...
    I'd vote for the unary & operator, since that makes most sense to me (as a C programmer)

    (It should be implementable with similar code to the unary - operator as well)

    Hi Owen,

    In your assembler you use @ to mean what we're calling @@@. Did you ever consider using & instead of @?

    No. While I could have done it, I did @ since the original definition of @ could not be supported by PASM (It's very hard to find the offset from the start of a Spin object which doesn't exist tongue.gif). When I was writing the RE2C for the scanner I was mostly cloning the operators from the Propeller Manual, and precedent from other assmeblers.

    My choice of & over @@@ is mainly because @@@ is overly long.
    mpark said...

    I dunno how you implemented the @@@ operator, but I ended up completely sequentially re-compiling my DAT and SPIN blocks until they stop moving about as the PBASE on each object changes. It's ugly but it works.
    PLink does pretty much the same thing when it's linking object files. It lays out all of the code into the buffer, which PASM has generated using the smallest size instructions it can generate (This only applies to LMM and VMM modes), then points all the symbols, before pointing all the relocations. If relocations don't fit, it enlarges the fragment and the instruction within and then repeats the process.

    As for library paths, my preference would be to do both an env var and an option. The environment variable would probably be soemthing like SPINLIB, and the option something like -Lpath, which may be repeated as many times as needed (This is how I intend to do it in PLink)
  • BradCBradC Posts: 2,601
    edited 2008-09-20 15:54
    OwenS said...
    and the option something like -Lpath, which may be repeated as many times as needed (This is how I intend to do it in PLink)

    Oh, brilliant.. I'd never even thought of that.. far easier than futzing about with os dependent delimiters!

    I guess it'll be -L on *nix and /L on Windows..

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • OwenSOwenS Posts: 173
    edited 2008-09-20 15:58
    Or just use -L everywhere, like PASM and PLink do (I portted FreeBSD's Getopt for Win32 :P )

    (The -L syntax comes from pretty much every Unix' ld by the way)
  • hippyhippy Posts: 1,981
    edited 2008-09-20 17:52
    mpark said...
    If you want to talk about bad code and architecture, I think Homespun will give you a run for your money. There's a reason I'm not sharing source code!

    I'm in the midst of the third re-write of the tools to handle C bytecode from LCC which is why it's all gone quiet on that front smile.gif

    I'd also argue for command line options over environment variables; makes it so much easier for people to write simple and 'thrown together' IDE's using Visual Basic etc using "Shell" to call it without having to get into incredibly complex stuff for people who aren't experts.

    Most of my re-write has been driven by making that as simple as possible and better dividing up the tool components.
  • OwenSOwenS Posts: 173
    edited 2008-09-20 18:27
    Hippy, would it be possible for you to provide me with some information on how LCC bytecodes map to your VM's instructions and such? I'd love to add it as a mode for PASM (and support for the resultant relocations to plink)

    Post Edited (OwenS) : 9/20/2008 6:46:23 PM GMT
  • hippyhippy Posts: 1,981
    edited 2008-09-20 22:42
    It should be possible to provide that.

    It's quite straight forward, two main categories; multi-byte constant loads ($80-$8F), single byte operations which work on the stack ($C0-$FF). On top of that single byte opcodes $00-$7F are optimised constant loads and $9x, $Ax and $Bx are additional optimised constants.

    There is some complexity though. Operations are dynamically allocated opcode values and both variables and constant load instructions can be automatically aligned to suitable word/long addresses to get the speed up. The kernel is dynamically built depending on what the needs of the bytecode is.

    More than anything it's a matter of being in the right frame of mind to document it.
  • OwenSOwenS Posts: 173
    edited 2008-09-20 23:04
    Oh - so it's a customized kernel like JDForth? That pretty much would make it very difficult to add support to it to PASM (Especially since I'd have to modify your kernel-dynamiscizer to generate PASM compatible assembly)
  • hippyhippy Posts: 1,981
    edited 2008-09-21 02:02
    Yes, and that's where the motivation came from. It actually generates a complete .Spin file with a Spin wrapper ( for debugging, testing and as an includable object ) with the assembled bytecode and necessary tables embedded. I finally managed to get Propellent.Dll working as well so I can compile straight to .Binary/.Eeprom, although I could equally call any of the third-party compilers to do that.
Sign In or Register to comment.