Paul Baker (Parallax) said...
How about a Spin to ASM converter that you can feed snippets of spin code and get code equivalent assembly out? People starting out in assembler could get alot of use and understanding out of the utility. The stack can be handled the same as spin, or for additional speedup you could·specify a buffer within the cog.
I agree!!! This would really help when learning.
Also folks who use spin can then optimize their code·by reviewing it in·PASM. Many of the PIC compiles I use work this way. I·write the code in a high level language then compile it, the compiler generates a hex file and·ASM file which I can review or tweak.
Post Edited (DynamoBen) : 2/28/2008 8:22:21 PM GMT
BTW the parser I'm working on could support something like a Spin to ASM converter. It just builds a tree and won't care about the output. Keep an eye on the "Spin Compiler" thread. Maybe in a few days someone can start a spin-off project.
Cheers,
--fletch
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Join us in the Un-Official Propeller IRC channel: irc.freenode.net #propeller
Newbies, oldies, programmers, math professors, and everyone in-between welcome! Propeller IRC howto
I completly support the idea of a compiler, as I need one for my Ubuntu Linux. I don't have much access to a windows computer (good for my health), and when I do, I cant program my prop. I doubt that the current Parallax compiler would run correctly in Wine, and even if it did, I can't get Wine due to the lack of internet.
Here·are all the source codes for the executable portions of the Propeller's ROM.
The booter and interpreter·binaries·appear scrambled when the ROM is read normally, but automatically unscramble when loading into a cog. Since Hippy succeeded in reversing the scrambling pattern in response to my·challenge, I'm revealing the source codes. I·hope this will yield more progress than headaches.
Note that the executable portion of the ROM ($F004-$FFFF)·was pre-filled with longs randomly picked from the interpreter's scrambled binary before the actual code was laid in. This was a feeble measure to obscure the boundaries of the interpreter and booter codes. It was not much of a deterrent to Hippy, however, as I'm not even sure that he noticed.
Here is a map of the executable portion of the ROM:
That's what I already did. But the discussion is only about running PASM code in the same cog running SPIN code. What I mean: Can the original bootloader of the Propeller (e.g. with a bootloader which is not waiting for RX to be high, if it goes down then it tries to boot from the external I2C eeprom and shutdown on fail ) be replaced with a bootloader that only uses an external I2C eeprom to fasten the boot-up process or alternative methods for booting (e.g. of a DataFlash or SD-/MMC-Card). I know that some kind of chainloading is possible with the existing bootloader (the original bootloader might load another loader).
Another idea in my head is, that a modified version of the propeller bootloader (PNut Booter) could act as a I2C master which sends his unique (specified) identifier to another microcontroller doing the firmware allocation. This could be a quite nice option in multi-propeller system (using
only one EEPROM or master bootstrapping device).
A possible idea would be: A master microcontroller (doesn't matter if it's a propeller) with some option of "storage" for byte-code,
multiple propellers attached to it requesting "their" firmware by sending their unique identifier. The master microcontroller would
silently ignore bogus request (e.g. unknown IDs, incomplete requests, etc.) and send only an ACK(nowledge) to the slave (one of the propellers).
After that, the propeller bootloader would reply with his ACK(nowledge) byte and start to exchange the firmware with the master.
6581, the Propeller ROM is mask ROM -- its program is set in the course of etching the chip. The Prop's CMOS process doesn't permit for EEPROM cells to be fabricated. So you'll have to settle for chain loading.
Spin may be a difficult language to write a compiler in. It's not impossible, but Spin's minimal string-handling capabilities will certainly make things awkward. However, if this can be done, a nice add-on would be a multi-threaded Spin byte-code interpreter that can run on a PC. For maximum portability, it should be written in Perl, Python, or some other thread-safe, multi-platform language (i.e. not VB6). It would be slower than Propeller-based Spin, certainly, but at least the Spin-compiler-in-Spin could run on other platforms besides the Propeller.
-Phil
Ok every one, I just found this thread and thought I'd ask...
Has anyone come up with a SPIN emulator that will run on a windows based PC?
6581, the Propeller ROM is mask ROM -- its program is set in the course of etching the chip. The Prop's CMOS process doesn't permit for EEPROM cells to be fabricated. So you'll have to settle for chain loading.
Okay thanks. My fault -- I tought that the Propeller has an electrically eraseable ROM (I found that info on some site)
Here·are all the source codes for the executable portions of the Propeller's ROM.
The booter and interpreter·binaries·appear scrambled when the ROM is read normally, but automatically unscramble when loading into a cog. Since Hippy succeeded in reversing the scrambling pattern in response to my·challenge, I'm revealing the source codes. I·hope this will yield more progress than headaches.
Note that the executable portion of the ROM ($F004-$FFFF)·was pre-filled with longs randomly picked from the interpreter's scrambled binary before the actual code was laid in. This was a feeble measure to obscure the boundaries of the interpreter and booter codes. It was not much of a deterrent to Hippy, however, as I'm not even sure that he noticed.
Here is a map of the executable portion of the ROM:
The links here are no good anymore. Can you repost them?
and that's not all that's not here anymore either, did you see all the people that used to be active on this forum, well over half that commented are long gone. But then again these days this forum is mostly about ebay, news, P2 wunderlusts, and social posts anyway
btw, if you want those files I might put a copy of them in my Tachyon Dropbox in a "Spin" sub-folder.
Comments
Also folks who use spin can then optimize their code·by reviewing it in·PASM. Many of the PIC compiles I use work this way. I·write the code in a high level language then compile it, the compiler generates a hex file and·ASM file which I can review or tweak.
Post Edited (DynamoBen) : 2/28/2008 8:22:21 PM GMT
Cheers,
--fletch
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Join us in the Un-Official Propeller IRC channel: irc.freenode.net #propeller
Newbies, oldies, programmers, math professors, and everyone in-between welcome!
Propeller IRC howto
Much appreciated,
Kevin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I am 1010, so be surprised!
Hey Chip,
So is it possible to customize it to my own needs and replace
the original bootloader on the propeller?
That's what I already did. But the discussion is only about running PASM code in the same cog running SPIN code. What I mean: Can the original bootloader of the Propeller (e.g. with a bootloader which is not waiting for RX to be high, if it goes down then it tries to boot from the external I2C eeprom and shutdown on fail ) be replaced with a bootloader that only uses an external I2C eeprom to fasten the boot-up process or alternative methods for booting (e.g. of a DataFlash or SD-/MMC-Card). I know that some kind of chainloading is possible with the existing bootloader (the original bootloader might load another loader).
Another idea in my head is, that a modified version of the propeller bootloader (PNut Booter) could act as a I2C master which sends his unique (specified) identifier to another microcontroller doing the firmware allocation. This could be a quite nice option in multi-propeller system (using
only one EEPROM or master bootstrapping device).
A possible idea would be: A master microcontroller (doesn't matter if it's a propeller) with some option of "storage" for byte-code,
multiple propellers attached to it requesting "their" firmware by sending their unique identifier. The master microcontroller would
silently ignore bogus request (e.g. unknown IDs, incomplete requests, etc.) and send only an ACK(nowledge) to the slave (one of the propellers).
After that, the propeller bootloader would reply with his ACK(nowledge) byte and start to exchange the firmware with the master.
Ok every one, I just found this thread and thought I'd ask...
Has anyone come up with a SPIN emulator that will run on a windows based PC?
Try Gear:
http://forums.parallax.com/showthread.php?t=100380
Okay thanks. My fault -- I tought that the Propeller has an electrically eraseable ROM (I found that info on some site)
Thanks Bob!
Man, I sure did miss ALOT while I was away!
The links here are no good anymore. Can you repost them?
and that's not all that's not here anymore either, did you see all the people that used to be active on this forum, well over half that commented are long gone. But then again these days this forum is mostly about ebay, news, P2 wunderlusts, and social posts anyway
btw, if you want those files I might put a copy of them in my Tachyon Dropbox in a "Spin" sub-folder.
It was included with all the FPGA variants Chip released.
See here
In the unlikely event that that stops working in the future, start at https://github.com/jacgoudsmit/P1V
===Jac