Basic Compiler or Basic to Assembly Translator

alex2

So far we have fairly slow, high-level, Spin interpreter and a faster, but more tedious to program with, assembler.

Is there any chance that a compiled basic (no interpreter) or basic to assembly translator projects might take off soon ?

I would like to see a very easy and efficient to use language like Basic without the OO stuff.

What is a chance that the project could get going through open-source ?

Any thoughts ?

Mike Green

Please read some of the other discussions posted over the last few months. You are not likely to see any kind of compiler for assembly language because of the memory limitations of the cogs (512 instructions per cog) which normally is the only place to run assembly programs. Bill Henning has done some work on what he calls Large Model Programs which runs a tiny interpreter in the cog which reads single instructions or blocks of instructions from Hub (main) memory to a cog and executes them with only a small speed penalty. You will likely see some kind of compiler for this (probably C first). This is all being done on a "hobby" basic, so it will happen slowly.

Note that Cliff Biffle has a partial Forth system for the Propeller

Also note that Spin is actually quite fast. You can do 19200 Baud serial I/O completely in Spin "bit-banging".

Brian_B

alex2,
I'm working torwards a on chip assembler, first I have to get hydra's basic working ,there is a bunch of stuff in there that will come in handy in a assembler , there are some memory problems to address(like Mike noted) but I'm hoping that the new asset managment software will help me out.

Brian

alex2

I am hoping that one of the future directions will lead to a Propeller with more onchip memory or a bootloader running code from external memory on some kind of 512-byte block (or whatever the size is) exchange multiplexed basis.

There is a discussion floating on the forum about wheather it would make more sense to add more cogs or more program memory.

Why not have two versions of the chip, one with bunch of cogs and smaller memories and other one with less cogs and larger memory ?

Gavin

Mike, is that what Bill has done? I better go back and have a look, did not understand it 1st time past, just that it was a major breakthough.

Dropping 512 blocks into cogs from main memory with maybe another cog fetching blocks from SD card or external SRAM.
Interesting possiblities, use one cog as smart MMU, intelligent DMA? The OO stuff could be interesting, nice way to package the 512 blocks.
Some way to manage everyones objects could come in real handy, my prop folder is a mess, lose track of versions of Mike's and Rokicki's code.

Gavin

JoannaK

alex2 said...
I am hoping that one of the future directions will lead to a Propeller with more onchip memory or a bootloader running code from external memory on some kind of 512-byte block (or whatever the size is) exchange multiplexed basis.

There is a discussion floating on the forum about wheather it would make more sense to add more cogs or more program memory.

Why not have two versions of the chip, one with bunch of cogs and smaller memories and other one with less cogs and larger memory ?

Alex2: I don't work for Parallax, so my thoughts arent' official nor do I have real numbers.. But I do know some things about electronic design/µP architechtures..

The memory, that will be added is the Hub-memory (32KB to 128KB), not memory inside cog... cog-memory is more difficult to add, cause there are no free Bits in instruction word for accessing more than 512 Longs of local memory.

For making two new chips?... Heck.. even making one costs hundreds of thousands USD (at least, may well be more) , with all prototypes, asic testing and requires many man-years of work. Asking them to do many different architectures is quite a lot..

Post Edited (JoannaK) : 2/5/2007 4:13:41 PM GMT

Mike Green

Gavin,
Bill's basic idea was that you could read an instruction from Hub RAM into Cog RAM slightly more than every 3 instructions on average and execute it inline. All the operands would have to be in the Cog which is usually not an issue. The jump instructions would have to be handled specially since you're really using the address pointer to Hub RAM as the program counter. Essentially you have:

:loop      rdlong  :next1,pc
             add      pc,#4
:next1   nop
             jmp     #:loop

although he "unrolled" this loop a couple of times (duplicated the code so there was a jump for every 4 "cycles"). That's one instruction about every 160ns. Still pretty fast. He also added multithreading and you could have a real stack if you want (with the stack in Cog RAM if you want) since jump type instructions are implemented as subroutine calls to routines in the Cog through a jump table. Read the threads on this.
Mike

Gavin

Gobbly gook,
Well not quite, been reading the manual and Andre's book at night and getting into the assembly instructions.
Bit hard to extend the instruction address range when limited to 9 bits, nearly ready to go back and look at Bill's code.
Starting to get excited about learning assembly for the first time in ages, I'm normally a hard core C guy but to get the most from this thing I am going to need assembly.

Discovering lots on holes and yet to be explained things in the manual, lots still to discover but they are still simple cogs.
An apnote on the Vid gen would help especially VGA, I keep on thinking up other uses for them that I don't know enough about that section to know if it will work. Compared to some micros a single cog is looking very simple, next stage is to figure out how they are connected. Probably should spend some more time pulling apart the assembly objects for more clues

Gavin

Paul Baker

Gavin said...
An apnote on the Vid gen would help especially VGA, I keep on thinking up other uses for them that I don't know enough about that section to know if it will work.

This will be the next Ap-note I will be writing, it is currently 3rd in my queue of things to do (after the datasheet and ESC). Until then Andre's book does a good job explaining that portion of the Propeller.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Gavin

Paul,
Yep figured it was on the list somewhere, 3rd is fine.
Andre does a good job for NTSC TV not so much info on VGA or PAL.
I really need to get into the assembly code, still only dabbling in spin.

I keep on thinking about using the vid gen as a high speed 8 bit output pattern generator.
Sticking byte patterns in ram and it spiting them out as PWM high freq 8 channels at once.
6 is all I need for PWM BLDC motors, but just don't know enough about the vid gen.
Changing the vid clock rate should change the motor speed. The high speed should allow for PWM sin wave drive.
Could even tweak the ram data for pseudo spread spectrum sin wave.
May not even need to learn assembly to do it?
Still reading between the line on the vid gen, hence hanging out for the ap note.

Gavin

Paul Baker

What you are talking about should be possible, (now here's the big if) if your specified update frequency is slow enough to accomodate spin's slow operational speed so your code can enter a WAITVID quickly enough. WAITVID was included into spin essentially because it didn't cost anything extra, while it doesn't have any real utility for generating video when used in spin, it could definitely have applications in lower bandwidth applications.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.