Shop OBEX P1 Docs P2 Docs Learn Events
Macintosh Support? — Parallax Forums

Macintosh Support?

Michael CookMichael Cook Posts: 1
edited 2006-06-28 08:03 in Propeller 1
Hi all. Ever since I first saw a little web link from somewhere I've been interested in the Propeller chip (this was before any of the documentation was up, just about the time it was publically announced). I got even more interested with the article in Nuts and Volts. There is just one problem... I'm a Mac guy.

Now I have virtual PC installed and I can use that if neccessary (although, for speed reasons, I'd like to avoid it). I know this route would work fine.

Is there a Mac OS X compiler/IDE in development? Even just a command line tool is fine. I'd just like to know if there is away to avoid messing with Windows for this.

I'm out of school now and I'd love to play with one of these while I job search. But I just don't think I'm up to going through all the Virtual PC hassle.

Comments

  • DeveloperZeroDeveloperZero Posts: 15
    edited 2006-06-23 02:10
    Check out the "Propeller and Operating System" thread.

    There is a complete discussion of the reason why there is only a Windows version, and I believe that someone is working on a command-line compiler (although I think it is only for Linux).

    However, if you at least have Virtual PC, you can run it on that. And if it is too slow, you can type it up in a text editor, then copy it over into the IDE in order to compile and run it. You lose the benefits of using the IDE like on a windows box, but at least you would have a working solution to program a Propeller chip.

    I wish you the best of luck, and ask that you merely reply with your results.
  • Mike GreenMike Green Posts: 23,101
    edited 2006-06-23 04:00
    I have a PowerBook (1.2 GHz G4) with the latest MacOSX and Virtual PC with Windows XP. It's not the fastest IDE under these circumstances, but it does work reliably as a Propellor development platform. I only use Windows for software that I simply cannot get in any other form. Maybe in a year or two I'll get a new MacBook so I can run the occasional Windows application at essentially full speed (when I can afford upgrading). In the meantime this will do.

    I don't expect Parallax to have a MacOSX version of the Spin compiler any time soon. They're very busy with what they already have to do and, I suspect, would much rather put their limited resources into a development platform that runs directly on the Propellor. There's already enough information publically available on the instruction set for anyone interested to write an assembler. Given the ease of running Windows software on newer Mac hardware, there's even less incentive for a MacOSX compiler. Linux is different enough from Windows, but there are several Linux programs for running Windows applications (like CodeWeaver's CrossOver Office). I haven't tested these, but they ought to work.
  • hammerhead74000hammerhead74000 Posts: 58
    edited 2006-06-23 06:12
    >> There's already enough information publically available on the instruction set for anyone interested to write an assembler.

    Where? Did I miss something? confused.gif

    It seems to me (unless I'm missing something) that more info on the assembler-Spin interface is required (so... the first thing to start running is the Spin interpreter, which then to start an assembler program, looks for... what?)

    Also, Spin is kinda integral to the whole Prop experience, so documentation on the interpreter's byte-code format would be necessary...

    As mentioned over in the SX forum, I have an IDE that I built for doing PIC and AVR work on OS X (using the GNU tool-chain); and I've started work on a simple tool-chain for the SX (I'm using C/Flex/Bison for the core tools - preprocessor, assembler, and basic compiler; the programmer - and if I can spring loose the details on the protocol, debugger - will be done as a Cocoa bundle that's loaded into my IDE as a plugin). I'm keeping an eye on the Prop; as I have a number of ideas that it would be just great for... it would be nice to be able to program it on the Mac (or Linux boxen, etc), too... smile.gif




    >> The Propeller Compiler itself is written in 32-bit assembly language for speed in execution and development (as we are very familiar with Intel x86 assembly).

    >> Chip the writer of the compiler thinks in assembly, its quicker for him to pound things out in it.

    More proof that Chip is, in fact, an alien... freaked.gifsmilewinkgrin.gif
  • cgraceycgracey Posts: 14,206
    edited 2006-06-23 09:05
    <----
    You can clearly see that I am, in fact,·a Muppet (not phoning home here, but ordering more pizza and wafers).
    hammerhead74000 said...

    >> Chip the writer of the compiler thinks in assembly, its quicker for him to pound things out in it.
    More proof that Chip is, in fact, an alien... freaked.gifsmilewinkgrin.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    Chip Gracey
    Parallax, Inc.

    Post Edited (Chip Gracey (Parallax)) : 6/23/2006 9:33:29 AM GMT
  • DeveloperZeroDeveloperZero Posts: 15
    edited 2006-06-23 11:24
    I agree with most of your points on the byte-code format, and wish there were more info (especially on the translation of spin -> assembly so I can write a program to allow·users to write code to·run on·the chip·as·a self-sufficient embedd PC, without implementing my·own interpreted language). I would like to know how the spin code interpreter works, and how I can take typed-in strings and convert them to a format that the interpreter can understand and use.
    However someone, I can't recall who, did post a pdf descibing the nuts-and-bolts of the Propeller (although I think it is just the first part of the booklet). I have attached it so you don't have to search·a bunch of threads. It includes a breakdown of the assembler opcode in detail.
    As for this quote:
    hammerhead74000 said...
    >> The Propeller Compiler itself is written in 32-bit assembly language for speed in execution and development (as we are very familiar with Intel x86 assembly).

    >> Chip the writer of the compiler thinks in assembly, its quicker for him to pound things out in it.

    More proof that Chip is, in fact, an alien... freaked.gifsmilewinkgrin.gif
    Chip isn't the only one who thinks in assembly. I find it more logical. It is very strict and straightforward. Beep
  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-06-23 12:27
    Guys, the byte code will not be released, Ive already asked it's not gonna happen. They feel it would be too much of a support nightmare, and I agree. However, theres nothing keeping you from reverse engineering the byte code. On the other hand, if you are a serious developer and have a high degree of "figure it out yourself"-ness you can ask in an offline manner about the bytecode, and they _may_ provide it if you're not going to ask a ton of questions requesting explainations on it.

    If you have any experience with assembly, the existing docs are more than enough to get you going (core docs.pdf mainly, this was the only docs received at the unveiling and I have written several routines based almost solely on page 5), they just aren't to the level of documentation that Parallax customers have grown to love and expect. Tech doc writing is an arduous task and they have other job duties besides writing those docs.

    Chip has released the preamble bytecode for programs in another thread, root around for it. There is a byte code for launching an assembler cog (also detailed in that thread). Other than that, Im not sure what else you're asking for.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Life is one giant teacup ride.

    Post Edited (Paul Baker) : 6/23/2006 12:31:03 PM GMT
  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-06-23 15:21
    Ok I hunted the thread down:
    Chip said...in http://forums.parallax.com/showthread.php?p=589824



    In the meantime, if you want to make a bootstrap loader for the Propeller, this is the only preamble you need:

    Minimal Spin bootstrap code for assembly language launch



    $0000: HZ HZ HZ HZ CR CS 10 00 LL LL 18 00 18 00 10 00
    $0010: FF FF F9 FF FF FF F9 FF 35 37 04 35 2C -- -- --


    $0020: your assembly code starts here - loaded into COG #0


    elaboration:

    $0000: HZ HZ HZ HZ - internal clock frequency in Hz (long)
    $0004: CR········· - value to be written to clock register (byte)
    $0005: CS········· - checksum so that all RAM bytes will sum to 0 (modulus 256)
    $0006: 10 00······ - 'pbase' (word) must be $0010
    $0008: LL LL······ - 'vbase' (word) number of longs loaded times 4
    $000A: 18 00······ - 'dbase' (word) above where $FFF9FFFF's get placed
    $000C: 18 00······ - 'pcurr' (word) points to Spin code
    $000E: 10 00······ - 'dcurr' (word) points to local stack


    $0010: FF FF F9 FF - below local stack, must be $FFF9FFFF
    $0014: FF FF F9 FF - below local stack, must be $FFF9FFFF
    $0018: 35········· - push #0·· (long written to $0010)
    $0019: 37 04······ - push #$20 (long written to $0014)
    $001B: 35········· - push #0·· (long written to $0018)
    $001C: 2C········· - COGINIT(0, $20, 0) - load asm code from $20+ into same COG #0
    $001D: -- -- --··· - filler


    $0020: XX XX XX XX - 1st long of asm program to be loaded into COG #0
    $0024: XX XX XX XX - 2nd long of asm program to be loaded into COG #0
    $0028:············ - rest of data


    everything from $00-$CE is the required preamble for all programs, $10-$1C is the minimum spin code required to launch into an assembler routine, replacing the current cog with the assembly code. $10-$1B become the stack ($18-$1B gets reclaimed as part of the stack once the byte code is executed), the arguments 0, $20, 0 are pushed on the stack via the byte codes at $18-$1B, then the bytecode at $1C pops the arguments off the stack and starts the assembly loading process.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Life is one giant teacup ride.

    Post Edited (Paul Baker) : 6/23/2006 3:31:02 PM GMT
  • hammerhead74000hammerhead74000 Posts: 58
    edited 2006-06-23 21:44
    Ahh... so I did miss something. OK - that should be enough to get going.


    >> They feel it would be too much of a support nightmare, and I agree.

    Hmm... I disagree, but only slightly -- it could be released as totally unsupported; and should anybody ask a bunch of dumb questions about it, tell em' to go pound bits... but, yeah, I can see how they wouldn't want to be in the business of trying to explain to newbies how it's internals work.

    >> However, theres nothing keeping you from reverse engineering the byte code.

    Hmm... yeah, but it's always better to have official documentation (even if that documentation was originally designed for "internal Parallax use").

    >> On the other hand, if you are a serious developer and have a high degree of "figure it out yourself"-ness you can ask in an offline manner about the bytecode, and they _may_ provide it if you're not going to ask a ton of questions requesting explainations on it.

    I wasn't asking (yet)... just speculating on what it would take to do some such thing. If I was to ask, then yeah -- I'd probably do so in person (I'm only about half an hour away from Parallax HQ - and that's just cuz' I tend to hit all the red lights going thru Folsom and out Douglas Bvld), and be willing to sign any requisite NDAs, etc...

    >> If you have any experience with assembly

    I do. Quite a bit, actually...


    >> they just aren't to the level of documentation that Parallax customers have grown to love and expect.

    I can be patient. smile.gif The Prop is, after all, brand-spankin'-new.

    >> Tech doc writing is an arduous task and they have other job duties besides writing those docs.

    Yes - it most definitely is.


    __________________________________________________________________________________________________________________________

    >> You can clearly see that I am, in fact, a Muppet

    Pigs - er, make that Bears in Spaaaaace, anybody? turn.gif

    Wokka Wokka Wokka! (ok, ok, I know.. that's your line) smilewinkgrin.gif
  • Cliff L. BiffleCliff L. Biffle Posts: 206
    edited 2006-06-28 04:44
    I've actually got a working assembler, though I don't have the full instruction set defined yet.

    I'm not interested in supporting SPIN; if I want to get 20KIPS in a high-level language, I'll write in C and underclock an AVR. smile.gif I'm looking into implementing Forth, but the weird memory architecture is giving me some trouble. (Forth without a stack or indirect addressing is...interesting.)

    The Propeller instruction set itself is pretty pleasant for assembly programming, though the Parallax syntax gives me a bit of a headache. I've implemented both the Parallax syntax and my own, Motorola-like syntax that doesn't rely on column position.

    It's in Java, so it should run on anything from a cellphone up, though be warned that Windows users are unlikely to get tech support unless someone mails me a copy. I'll post sources if people are interested.
  • GadgetmanGadgetman Posts: 2,436
    edited 2006-06-28 08:03
    I just got the Propeller IDE up and running on my 1.33GHz G4 iBook...

    I'm using GuestPC, though, not virtualPC as it's not only cheaper, but it's also NOT made by M$.

    I did have some problems with GuestPC/winXP not detecting the FTDI adapter I'm using, but then I went into the control panel/System/Hardware(whatever) right-clicked on COM3 and selected update driver and pointed it to the FTDI driver I downloaded from Parallax. The next time I connected the FTDI device, it detected a new device and ran the usual wizard, and now all is well...
    (Except that I have almost enough time to make a cup of tea while the Propeller IDE starts... )

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Don't visit my new website...
Sign In or Register to comment.