PBASIC2.5 and the propeller..

deno

Please don't yell at me for this....but for a long time know, I have been working with the Basic Stamp modules in PBASIC.· I have read the Propeller Manual, thru and thru, and the absence of things like ENDIF, or NEXT and the use of things like ~~ and !·just throw me for a LOOP.· (No pun intended).· Do you think the day will come when the Propeller can be programmed in PBASIC.· I do have real needs to be able to run different COGS or programs at the same time, but I guess I am to old to learn new tricks.· As an example, the photo at left of ROBO CHILD (as the wife named it...I think she hates our child?) has 4 stamps doing various jobs, and having to communicate with each other serially.

Further more, and I would like to think I have some programming skills, the Propeller Manual 1.0 is just a little difficult to read.· Now I know, that thousands of you already know how to program or write software for the Prop, and you were self tought, so I should be able to learn the language.· Brain cells are becomming increasingly harder to find at my advancing age.· My brains DATA and program EEPROM space is starting to converge on one another.

So I am just asking here...if the Propeller can be programmed in SPIN and assambly, then why not an interpeter version for PBASIC.

Other then that, I do enjoy working with and using Parallax products and will continue to do so.· Generally, once I find something that I can works, I stay with it.

DenO

Post Edited (deno) : 7/30/2009 12:46:47 PM GMT

Bean

Deno,
I have just begun working on such a compiler/translator program. It will likely require two cogs, one that runs the spin code that the PBASIC is translated into, and another to assembly code to do many of the high-level commands (such as SERIN, SEROUT, I2C, 1-Wire, etc).

Right now I'm a little side tracked by LMM assembly because I suspect the assembly for the "helper" cog will exceed 496 instructions.

One problem will be that spin does not have a GOTO command. So the PBASIC will HAVE to use structured programming without the use of GOTO (unless Parallax adds "GOTO" to spin).

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...


·

Bill Henning

Hi Bean,

There is actually a GOTO spin byte code instruction... you just have to generate it. $3C i think.

I'm looking forward to trying your Basic.

Bill

Bean (Hitt Consulting) said...
Deno,
I have just begun working on such a compiler/translator program. It will likely require two cogs, one that runs the spin code that the PBASIC is translated into, and another to assembly code to do many of the high-level commands (such as SERIN, SEROUT, I2C, 1-Wire, etc).

Right now I'm a little side tracked by LMM assembly because I suspect the assembly for the "helper" cog will exceed 496 instructions.

One problem will be that spin does not have a GOTO command. So the PBASIC will HAVE to use structured programming without the use of GOTO (unless Parallax adds "GOTO" to spin).

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Morpheus & Mem+ Advanced dual Propeller SBC with XMM and 256 Color VGA
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full

photomankc

I know what you are asking but I would suggest going ahead and getting a board to work with and running through the Labs in the Propeller Education Kit Manual. The labs are good and the manual is free to download! At first I thought it looked pretty intimidating as well but you understand it 10 times better if you can work through the examples and then modify them a bit as you get to understanding the operation. I was off and running in a few hours after I built out the basic circuit on my breadboard from parts. I'm totally a learn-by-doing type. I can read it 50 times but before I can wrap my head around it I have to get my hands on it and experiment a bit. My guess on why not both would be the space that would be required for both token tables to keep them resident at the same time and the complexity that would be needed to swap them if they weren't both loaded.

What I am waiting/searching around for is a Spin compiler that would take a Spin program and convert it to ASM/Machine Language. The speed of Assembler is great but I would rather beat myself with a hammer than write original code in it. Maybe that's how you would feel about Spin but I bet you would not have as much difficulty once you started putting your hands on it as you think you will just reading it.

ericball

photomankc said...
What I am waiting/searching around for is a Spin compiler that would take a Spin program and convert it to ASM/Machine Language. The speed of Assembler is great but I would rather beat myself with a hammer than write original code in it. Maybe that's how you would feel about Spin but I bet you would not have as much difficulty once you started putting your hands on it as you think you will just reading it.

I think you will be waiting for a long while for a SPIN to PASM compiler - the two environments are quite different.· PASM has to live in 496 longs (instructions, registers & "local" variables), while SPIN can use all 32K of HUB RAM.· PASM has no stack but it can use COG RAM as a massive register store while SPIN is a typically HLL with functions and variable passing (typically implemented using a stack).

This is not to say it's impossible, but I suspect a PASM target would place significant restrictions on the SPIN code.· Maybe an LMM compiler (like Catalina) would be possible, but then you would lose a lot of the speed benefit.· (Except for hand coded PASM "kernel routines", but then that's almost an interpretter.)

Also, one of the advantages of PASM is it's deterministic and is partial to hand optimization.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum

Bean

I think a document explaining how to translate PBASIC to SPIN would helpful.

For Example:
PBASIC FOR A = 1 TO 10
SPIN REPEAT A FROM 1 TO 10

Of course alot of the high-level commands (SERIN, SEROUT, I2C, 1-Wire, etc) will not be so easy to translate. I think this is where alot of the PBASIC crowd gets frustrated.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...


·

photomankc

ericball said...

photomankc said...

What I am waiting/searching around for is a Spin compiler that would take a Spin program and convert it to ASM/Machine Language. The speed of Assembler is great but I would rather beat myself with a hammer than write original code in it. Maybe that's how you would feel about Spin but I bet you would not have as much difficulty once you started putting your hands on it as you think you will just reading it.

I think you will be waiting for a long while for a SPIN to PASM compiler - the two environments are quite different. PASM has to live in 496 longs (instructions, registers & "local" variables), while SPIN can use all 32K of HUB RAM. PASM has no stack but it can use COG RAM as a massive register store while SPIN is a typically HLL with functions and variable passing (typically implemented using a stack).

Ahhh. I see then. Noted, so perhaps one of the C compilers would be more useful if the application gets much larger than the hub can support. I like the Spin syntax better than C though. C was always about as low of a HLL as I could go before it stopped being fun to program for me. Spin has the stuff I like from C without all the file/library/etc management overhead. I'm brand new to this though so I'm not well versed in the guts of the Propeller.

StefanL38

to clear things up

you have 2KB of cog-RAM organized as 496 longs (32bit values) and 32kB of hub-ram.
the c-compilers use the LMM (large-memory-model) to copy small pieces of PASM-code from hub-ram to cog-ram while PASM can ONLY
be executed in cog-RAM.

SPIN loads SPIN-byte-codes from HUB-RAM to interprete the bytecode. 32kB of bytecode can hold much more codelines than 32kB of PASM-code
as long a you do not need high-speed in your program SPIN is the way to go.

best regards

Stefan

ericball

StefanL38 said...
the c-compilers use the LMM (large-memory-model) to copy small pieces of PASM-code from hub-ram to cog-ram

A "pure" LMM copies each PASM instruction one by one from HUB RAM to COG RAM, where it is executed.· (i.e. The LMM doesn't copy blocks of PASM to COG RAM, execute the block, fetch the next block.)· However, as there are PASM instructions which cannot be executed in this fashion, they can be implemented as "kernel routines" which are contained in COG RAM along with the LMM.· These kernel routines can be invoked by the LMM fetched PASM code and executed at full speed then returning to the slower LMM fetched PASM code.· This could conceivably be used in a hybrid fashion, blurring the lines between PASM code and LMM fetched PASM code.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum

deno

Thank you for all the replys...some of which I don't understand...LMM, PASM,HUB RAM, etc. Anyway, I thought I would just ask...

DenO

Nick Mueller

> but I guess I am to old to learn new tricks.

You are only getting old, when you stop learning!

SPIN isn't the most elegant language (neither is BASIC), but if you work through the book and make all examples, play around a bit, you'll get that. Even as an "old fart".

You can build robots, design communications protocols (that is an higher and more abstract level; requires more brain!) then you can learn SPIN.


Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO