FlexBasic.....For "COG"

Mickster · 2021-11-24 19:33

Anyone figured out how to use this?

I only get compiler complaints. I suspect that there is some kind of initialization that I'm missing.

ersmith · 2021-11-24 21:43

Here's an example:

function for "cog" addup( a() as integer, n as integer) as integer
  var sum = 0
  for i = 0 to n
    sum += a(i)
  next i
  return sum
end function

dim shared testarr(4) = { 1, 2, 3, 4, 5 } as integer

print "sum = ", addup(testarr, 4)

There are significant restrictions on functions placed in COG and LUT memory; see the general compiler documentation for details. In particular, the functions should be leaf functions (not call any other functions... in theory they could call other COG or LUT functions, but the compiler doesn't allow that yet).

ersmith · 2021-11-24 22:04

Hmmm, I may have spoken too soon about the leaf function restriction... it looks like that was lifted a while ago.

Mickster · 2021-11-26 05:56

But I can't just launch something like this, right?

dim shared as long cogtest

sub for "cog" addup( )
do
    cogtest = cogtest + 1
loop
end sub

addup
do
    print cogtest
    pausems 200
loop

evanh · 2021-11-26 08:33

If I'm reading Eric correctly, it doesn't start a separate task. The for "cog" feature is just a way to specify routine to be compiled for cogexec rather than the default hubexec.

JRoark · 2021-11-26 12:01

@evanh said:
If I'm reading Eric correctly, it doesn't start a separate task. The for "cog" feature is just a way to specify routine to be compiled for cogexec rather than the default hubexec.

Correct.
The code @Mickster posted will jump into Addup() and never return, as Addup() runs in the same cog that has called it. But if you spawn Addup() into its own cog (with its own stack pace, etc) the code will run as intended, with the value of cogtest being printed every 200 mS.

ersmith · 2021-11-26 12:51

Right. FOR "COG" means the function is to be placed in COG memory (and FOR "LUT" means it is to be placed in LUT memory) but the function will still run in the same cog as the rest of the program. To start a new cog you need to use the CPU pseudo-function:

dim shared as long cogtest
dim as long stack(20)

sub addup()
do
  cogtest = cogtest + 1
loop
end sub

var id = cpu(addup(), @stack(0))  ' run addup() in a new COG with its own stack
print "cog "; id; " started"
do
  print cogtest
  pausems 1000
loop

Mickster · 2021-11-26 13:43

@ersmith said:
Right. FOR "COG" means the function is to be placed in COG memory (and FOR "LUT" means it is to be placed in LUT memory) but the function will still run in the same cog as the rest of the program. To start a new cog you need to use the CPU pseudo-function:
dim shared as long cogtest
dim as long stack(20)

sub addup()
do
  cogtest = cogtest + 1
loop
end sub

var id = cpu(addup(), @stack(0))  ' run addup() in a new COG with its own stack
print "cog "; id; " started"
do
  print cogtest
  pausems 1000
loop

Oh yeah, I already have a couple of these happening but I misunderstood it to be like running a routine permanently in only cog memory. Like, with the P1; in cog-mode you get the full 20MIPS but only 4 or 5 MIPS using LMM (?)

evanh · 2021-11-26 14:39

All correct. But it's the same cog as was being used to execute in LMM, just like one cog that executes hubexec or cogexec. Your main program is using a cog, and a subroutine/function, in hubexec or cogexec, is still running on the same cog unless a new cog is explicitly launched. Prop1 with LMM is same in this respect.

Mickster · 2021-11-26 15:36

@evanh Understood, many thanks

ersmith · 2021-11-26 18:27

@Mickster said:
Oh yeah, I already have a couple of these happening but I misunderstood it to be like running a routine permanently in only cog memory. Like, with the P1; in cog-mode you get the full 20MIPS but only 4 or 5 MIPS using LMM (?)

The difference isn't that extreme in P2 mode, plus FlexBasic already caches loops in COG memory (which further reduces the penalty). So generally it's fine to run code in HUB memory. But if you want extra reliable timing, or have a very frequently used function, then FOR "COG" and FOR "LUT" may be useful. And of course you can combine them with CPU -- that is, if you want a subroutine to run permanently in another cog and be in internal memory in that cog, make the subroutine FOR "COG" or FOR "LUT" and then launch it in the new cog with a CPU command.

Mickster · 2022-09-16 10:28

@ersmith said:
if you want a subroutine to run permanently in another cog and be in internal memory in that cog, make the subroutine FOR "COG" or FOR "LUT" and >then launch it in the new cog with a CPU command.

Hi Eric,

Been trying to make this work but the compiler complains that the sub needs to be in hub memory.
Don't suppose you have an example, please?

Also, from the manual:
What exactly is "noinline"?

Craig

ersmith · 2022-09-16 13:59

@Mickster said:

@ersmith said:
if you want a subroutine to run permanently in another cog and be in internal memory in that cog, make the subroutine FOR "COG" or FOR "LUT" and >then launch it in the new cog with a CPU command.

Hi Eric,

Been trying to make this work but the compiler complains that the sub needs to be in hub memory.

D'oh, I forgot about that restriction. But to work around it is straightforward, just have a small stub function that launches the COG/LUT function, e.g.:

sub for "cog" blink()
   do
     pintoggle(57)
     pausems 200
   loop
end sub

sub blinkstub()
  blink()
end sub

dim stack as byte(128)

var cogid = cpu(blinkstub(), @stack(0))

do
   print "running in cog "; cogid
   pausems 2000
loop

I'll see if I can make the compiler generate that stub automatically if necessary.

Also, from the manual:
What exactly is "noinline"?

It says the function/subroutine should never be made inline. Normally if the routine is small, or is only called from one place, the compiler expands it in place instead of creating a CALL instruction. For example, in code like:

   function incr(x as integer) as integer
      return x + 1
   end function
   ...
   b = incr(c)

the generated assembly will be exactly the same as if you had written

   b = c+1

because the "incr" function is simple enough that the compiler can just do it "in place". If you specify that "incr" is FOR "noinline" then instead the generated assembly will contain a subroutine for incr and the code will include a CALL.

Mickster · 2022-09-16 20:09

@ersmith

Perfect 🤓.... Many thanks 👍😎👍

Craig

FlexBasic.....For "COG"

Comments