propBASIC response

Rsadeika

Do not know if you have finalized the compiler yet, but, would you consider renaming the 'TASK' to 'THREAD', and set it up so you can run a 'TASK(s)' within the 'THREAD(s)'? Seems like a cog is a terrible thing to waste, on just a simple task IMO.

<edit> This was supposed to be a response to Beans thread, somehow it got away from me. I put in a subject line, but it is not appearing in the subject line.<edit>

Post Edited (Rsadeika) : 11/10/2009 5:33:01 PM GMT

Bill Henning

Actually, you meant PropBasic

PropBasic = Bean's pasm based compiler
PropellerBasic = my LMM basic compiler

Bean uses "TASK", I use "COGNEW"

Rsadeika said...
Do not know if you have finalized the compiler yet, but, would you consider renaming the 'TASK' to 'THREAD', and set it up so you can run a 'TASK(s)' within the 'THREAD(s)'? Seems like a cog is a terrible thing to waste, on just a simple task IMO.

<edit> This was supposed to be a response to Beans thread, somehow it got away from me. <edit>

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller

Bean

TASK is specifically for code you want to run in a seperate cog.

You can create SUBs for code that runs in the same cog.

The propeller doesn't have interrupts, so there is no way to make code that runs at timed intervals like on the SX.

Bean.

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


·

pjv

Hi Terry,

In regard to your statement..... 'no way to make code that runs at timed intervals like on the SX', you need to be aware that I am writing a very compact (approximately 35 instructions) assembler based multi-threading co-operative scheduler to do just that. It can be loaded into any number of cogs, and within each of those cogs can run any (reasonable) number of independently timed threads 'simultaneously' as directed by the scheduler. At this point the context switch is around 0.5 uSec, and the context storage consumption is only one long per thread. Furthermore, the user's application threads can be (should be) written in state-machine format, making repetitive and sequential applications a breeze.

For example, a LED flasher threads comprises two longs; XOR outa,#LedBit plus JMP #Scheduler, and the TX and RX UART's are 18 and 35 instructions respectively.
Already I have run multiple independent TX and RX UARTs at different baud rates in a single cog.

As proof of concept, I expect soon to demonstrate 128 simultaneous trivial (like LED flasher) independent threads to operate in each of 8 cogs, for a total of 1024 threads. Since only 32 I/O bits are available 32 threads will access each LED in a coded format to prove all threads running.

The practical fastest speed is a sequencer tick per 10 uSec although I have run contrived threads as fast as 1 uSec.

I believe it will be very easy for you to imbed this scheduler kernel into SX/B propBASIC

Cheers,

Peter (pjv)

Post Edited (pjv) : 11/10/2009 11:55:54 PM GMT

StefanL38

Hey Peter,

that sounds really coool. Will you add extensive documentation an examples (by the time) ?

best regards

Stefan

Rsadeika

Sounds like pjv has the answer for making propBASIC a really, really fantastic language, just my opinion. Anybody else share my viewpoint?
Ray

JonnyMac

@Peter: When will you be posting your scheduler kernel for us to play with? I had a little trouble with the SX version but feel much more comfortable with PASM so I think I might just be able to make it work in my little projects.

pjv

Hello Jonny;

It's real close (ought to be for only 35 or so instructions!), but in trying to keep it as tight as possible, the timer roll-over boundary conditions are still in need of some tweaking. I hope to get it out before I leave on vacation next week.

Cheers,

Peter (pjv)

pjv

Hi·Jonny & Gang;

Looks like I've got it cased. I was actually able to reduce the code by 5 instructions, so we're sitting at a kernel size of 30 instructions, and a top speed for a trivial LED flasher of about 3 uSec.

A thread context switch, depending on how you define it, is just over 0.5 uSec.

More extreme limit testing tonight, but this looks real fine! --- took long enough!

Cheers,

Peter (pjv)

pjv

Hi All;

An update;

As proof of the multi threading concept, I now have 128 separate trivial LED flasher threads running in a single cog, each one flashing at a different rate.

I invoked this test in stages.... 32 threads took about 30 uSec for all to to execute, 64 took about 60 uSec, and 128 take about 120 uSec. It scales very nicely.

Obviously each of the other cogs could also be made to do this for a total of 1028 simultaneous running threads.

Can one do this with any other micro??··· In many ways Propellers ROCK !!

Next I will do a bunch of UART Transmitters with different baud rates.

Cheers,

Peter (pjv)

Post Edited (pjv) : 11/12/2009 5:54:02 PM GMT

Rsadeika

Sounds really exciting pjv, now, if Bean decides to incorporate your code into propBASIC, not only will the propeller ROCK, so will propBASIC ROCK.

JonnyMac

It's a little unfair to expect Bean to incorporate a programming philosophy into PropBASIC that isn't of his own design -- in my opinion, he was berated into including TASKs into SX/B which, ultimately, generated a lot of code without being terribly useful. Let PropBASIC be what it is and learn to use it as it stands before being too critical, espeicaly since PropBASIC will be made available to you at no charge.

PJV is an exceptionally-gifted programmer and I'm looking forward to his threading engine. That said, if it ends up in one of my PropBASIC programs it will happen because I did it on my own. PropBASIC supports ASM...ENDASM blocks which means we are free to customize at will.

Bean

Thanks Jon.
Yes, TASKs was a cute feature. But it took loads of my time to implement and get working. And it never was a very useful feature. The overhead was too large.

Being that the propeller has 8 cogs, and can do 8 tasks at full speed. I don't see the need for multi-threading in PropBASIC.

I think it is a great technicial achivement, and I don't want to belittle PJV in any way. I just don't see the benefit in PropBASIC.

Bean.

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


·

Rsadeika

@Jonny, "... if Bean decides to incorporate your code into propBASIC ...", to me, it does not sound like a berating. Now as for the actual SX/B, I believe I was the one that made the suggestion to add a task like feature when it was in beta testing, and do not recall berating him to do it. I do not recall anybody berating Bean in to doing anything, while it was in beta testing, it was all done as suggestions. In the end, Bean could of ripped out the code before going public with the software, then nobody would have been the wiser.

At this point, concerning propBASIC, all Bean has to say is, that the compiler design is finalized, and basically it will not change from what it looks like at this moment, end of story. No berating to be contemplated; I know this is free software, what you get is what you will use. I also made my decision about possibly being a beta tester, I would have nothing to add to the procedure.