Question about F32 and interaction with other objects

Rforbes · 2012-06-06 17:15

Hello everyone,

Long time reader, first time writer!

I have a question about using objects (F32 and my own) and I'm not exactly sure how to word this properly. So please bare with me, I'm still getting my feet wet with the Propeller. (The last languages I programmed in were dBase III+, Clipper 5.0 and Fortran! haha!)

Here's the scenario:
My main object starts up F32 in another cog.
I have several methods that all need to use F32 commands at various times, and I'm sure at some point more than one of these methods will attempt to use the same F32 method at the same time.

For Instance, Method A calls the fp.FAdd method, and a few clocks later Method B calls the fp.Fadd method as well.

My question is- Do I need to be concerned with this? If the first call to fp.FAdd isn't completed before the second call comes, what will happen? Does it que up and start as soon as the method is available, or will it mess things up?

Any information/food-for-thought would be greatly appreciated. Thanks in advance!

Robert

Mike Green · 2012-06-06 17:28

Yes, you need to be concerned. F32, like most objects that use a cog running assembly language, uses an area of hub memory for communication between the Spin routines that you call and the assembly code. This area of hub memory has to be shared if more than one cog running Spin can try to use it. You share these things by using the LOCKxxx instructions and Spin statements. Under very specific circumstances, you can share such a communications area. FullDuplexSerial is one example of this where the transmit and receive buffers along with the pointers into the buffers are shared without the use of a lock / semaphore. F32 doesn't fit this paradigm, so you'll have to use locks.

Rforbes · 2012-06-06 17:40

Mike- Alright, thanks for the information. I'm still not quite clear on how to implement locks but I'll keep at it. Was sort of hoping it wouldn't be an issue but I guess they didn't build the propeller to the standards of "Me."

Mike Green · 2012-06-06 17:51

Read the sections of the Propeller on the LOCKxxx statements. LOCKNEW is something you call when you initialize your program and you save the lock # you get in some kind of global variable (like in lockId). You also need to make sure the lock is free by doing "lockclr(lockId)". If your program ever exits, you'd call LOCKRET to release the lock #.

Before one of your cogs calls F32, it needs to do "repeat while lockset(lockId)". After the cog is done with F32, it needs to do "lockclr(lockId)". You could build all the lockset and lockclr calls into the F32 methods, but this would restrict access to F32 on a method by method basis ignoring the fact that you usually make several calls to F32 in a row and this would add overhead to each F32 call rather than just before and just after a complete floating point calculation.

Rforbes · 2012-06-06 18:06

Ah, I'm reading the stuff again and it's making more sense. Will give it a try this evening and see what happens. I might be in for some code re-writing, because I've used a few globs of nested calls like D2:=fp.FDiv(D1,fp.Fdiv(NewDP,fp.Fmul(0.5,fp.Fadd(NewFin,NewInit)))) in some methods and other methods just call a single fp.Fxxx for something or other.

Maybe I'd be better off using multiple instances of F32 so that certain methods use F32[0] and others that might try to call at the same time use F32[1]? I think I can do that without running out of cogs.

I've given my brain plenty of exercise for a bit- gonna go eat dinner. Thanks again.

Robert

Mike Green · 2012-06-06 19:33

Using separate instances might be the best way to do this. I think it would cost you under 64 bytes of memory for each instance with the code shared across all instances, but each F32 instance would use a cog as well.

Duane Degn · 2012-06-06 20:23

In post #9 of this thread, I attached an archive which includes a version of F32 to be used within multiple objects.

I just moved the variables from the VAR section to a DAT section so they would remain the same for the various objects using F32. If more than one cog uses this version at once, you'll still have trouble.

While the version I just mentioned has been tested, I just made another version which I don't have time to test right now.

The version attached to this post uses locks. If F32 is in the the middle of a calculation, the new call will wait until it finishes the calculation before commanding a new calculation.

The Start method checks out a new lock. The ID of this lock can be obtained by calling the "LockUsed" method. Normally you wouldn't need to call the "LockUsed" method since the modified F32 takes care of checking out the lock and returning the lock when/if the Stop method is called.

To use this version of F32, it would be best if only one cog calls the Start method. You'll need to list it as an object from any object calling its functions.

I'm not at all sure I did this correctly. I'll try to test this version out in the next day or two. If you use it, let me know how it works.

Mike Green · 2012-06-06 20:45

FMax and FMin won't work in your version because these return before the lockclr(lock) is executed. Try these instead:

PUB FMin(a, b)
{{
  Minimum: result = the minimum value a or b.
  Parameters:
    a        32-bit floating point value
    b        32-bit floating point value  
  Returns:   32-bit floating point value
}}
  repeat until not lockset(lock)
  result  := cmdFCmp
  f32_Cmd := @result
  repeat
  while f32_Cmd
  lockclr(lock)
  if result < 0
    return a
  return b
  
PUB FMax(a, b)
{{
  Maximum: result = the maximum value a or b.
  Parameters:
    a        32-bit floating point value
    b        32-bit floating point value  
  Returns:   32-bit floating point value
}}
  repeat until not lockset(lock)
  result  := cmdFCmp
  f32_Cmd := @result
  repeat
  while f32_Cmd
  lockclr(lock)
  if result < 0
    return b
  return a

"repeat until not lockset(lock)" is functionally equivalent to "repeat while lockset(lock)", but I think the latter version is a little faster.

Duane Degn · 2012-06-06 21:18

Mike Green wrote: »

FMax and FMin won't work in your version because these return before the lockclr(lock) is executed.

You're right. I shouldn't have posted this code yet. I made the changes too quickly.

I'll test it out a bit tomorrow.

I'd suggest others not trust the code I posted. Hopefully it won't take too much work to make useful to multi-object and multi-cog applications.

Mike Green wrote: »

"repeat until not lockset(lock)" is functionally equivalent to "repeat while lockset(lock)", but I think the latter version is a little faster.

I set locks the way I saw Kye set them. I like your method better. I think it makes more sense to me than the "until not" version.

Thanks for the pointer and thanks for pointing out the error in my modified version F32.

I really shouldn't have posted such unproven code.

Heater. · 2012-06-07 00:43

Rforbes,
Welcome to the forum.
Actually your opening post talks of only a main object running, starting F32, and then making various calls to F32 from different methods. Provided no other cogs are started, which the post implies, then no locks are required for this to work correctly.
You will need some kind of mutual exclution if your main object is indeed starting some of it's methods in other cogs or you have other sub objects that do so.

Rforbes · 2012-06-07 05:52

Thanks everyone,

Duane, I'd love to see the F32 capable of handling multicog and multiobject applications. That's pretty much exactly what I'm in need of, but I honestly don't have enough skill yet to determine whether it would serve my purpose or not without trying it.

This is great information. I'm unable to devote hours and hours to studying and learning Spin and Assembly right now, so it really helps to see all of your input and information.

Heater- I think I didn't explain fully how my code "should" work. You hit it on the head- My main object starts some of its methods in other cogs, and each of these methods needs to use F32 at various times. So there is a good possibility that method A will try to call one of the F32 methods while Method B is currently using that exact same method.

The frustrating part is that I'm trying to use calls to F32 around 1500 times per second- so adding more code (such as the lockxxx commands) in my repeat loops adds overhead to the loop time between each call. Each loop iteration performs several calls to F32. I need fast loop iteration more than I need memory or free cogs, so I'm starting to think running multiple F32's is the right way to go. That way I'm (hopefully) able to squeeze every last bit-O-speed out of the loop iterations in each method/cog that needs to use F32 to do it's work.

I don't have my code with me right now, but I'll try to post some of it later. Maybe there is a better way to do what I need- quite likely, actually.

Thanks again,
Robert

Rforbes · 2012-09-05 18:06

Hey all,

Just wanted to give a quick update and say THANKS to you all.

I decided to just run multiple instances of F32, and it works great. Since all my code is written in SPIN, it's a bit slow. But, I'm thinking of trying to tackle some assembly and see if I can speed things up a bit.

Again, Thanks!!

Question about F32 and interaction with other objects

Comments