Mutex in a struct?

[mcsummation]

Code: Select all

struct stuff {
    mutex m,n;
    byte b, c;
};

mutex p;
stuff MyStuff;

void stuffit(stuff &q) {
    q.b = q.c;
    q.n = q.m;
    Acquire(p);
  Acquire(q.m);
}

task main() {
stuffit(MyStuff);
  Acquire(MyStuff.m);
}

All the weird, seemingly useless junk is simply there to show what all works. However, the Acquire(q.m); won't compile. Tell me why. Alternately, how do I fix it. All the various options on the function (safecall/inline) have no affect. Just to satisfy my self that a mutex could be in a struct, i added Acquire(MyStuff.m);. There is probably a simple explanation. I await enlightenment.

[afanofosc]

I need to update my help docs a bit. The word "cluster" refers to a struct.

The NXT firmware stores mutex records as flat 32-bit data structures. However, mutex records
are not treated as normal scalar values, and you cannot store mutex records in arrays or clusters.
The only two instructions that can operate legally on mutex records are OP_ACQUIRE and
OP_RELEASE. Refer to the Instruction Reference section of this document for information about
these functions

http://cache.lego.com/upload/contentTem ... B2A1F6.pdf

John Hansen

[mcsummation]

To quote my favorite bear, "Oh Bother!"

OK, back to the drawing board. I may have lost the skirmish, but the battle will still be mine!

Edit: It appears you can't pass them as arguments to a subroutine, either. I will prevail!

John, I know what you said back up there. However, I just have to try options. It's in my nature.

[afanofosc]

The only two instructions that can operate legally on mutex records are OP_ACQUIRE and OP_RELEASE

If you wanted to pass a mutex as an argument that would require the MOV opcode or some other kind of opcode that does not exist.

You can pass a mutex into a preprocessor macro that pretends to be a function. It will be a lot like an inline function.

John Hansen

[nxtboyiii]

Since were talking about structs, will having functions inside a struct ever be possible?

[mcsummation]

How big (number of lines) can a preprocessor macro be? Naw, don't answer that. I don't like the idea of a preprocessor macro the size of this routine. Macros have their places and I write them to replace a reasonable number of characters with a few. But, to basically replace an entire subroutine when there's an easy way to do it without the macro, nah, the user has to write part of this code. If he doesn't follow my rules (for using this library I'm writing), then it's on him to figure out why the stuff doesn't execute properly. You may trashcan the whole thing anyway.

[mcsummation]

Since were talking about structs, will having functions inside a struct ever be possible?

Do you mean like "a pointer to a function"?

One of my ideas had to do with doing that. However, if I can't hide a mutex in there, I kind of lost interest. Mine was even worse than a simple struct - I wanted a function pointer inside a struct which was an element of an array inside a struct. Lost? I hope so - I got lost designing it this morning. However, I'll store a byte "element encoding type" and let the poor user handle whatever kind of switch statement it takes to unravel it.

Actually, now that I think about it some more, one of the more obscure interfaces I have used couldn't do a simple call/return (I don't remember why). They set up the stack (stack, someone mention a stack?) and "returned" to you. I don't remember what you did when you got through, maybe called them. So, John said, back up in my thread about preemption and how safecall worked, that the end of a subroutine is actually a jump to the return point, rather than a "return". So maybe a little self modifying code (at the NBC level) would let you do what amounts to a "vectored jump", which might do the trick. And, I'm not afraid of self-modifying code. I worked on a machine years ago that didn't have a "move x number of bytes" (where x was in a register), you had to write your source as "move 3 bytes from abc to xyz", then at run time you plugged in the actual number of bytes over the "3" and then ran headlong into that instruction. They only lost control at times of their choosing, so didn't have to worry about the code getting stepped on. The first time I saw some of their code I had a small stroke.

I'm just waiting on John to jump back in here and tell me how full of beans I am.

[mcsummation]

You can pass a mutex into a preprocessor macro that pretends to be a function. It will be a lot like an inline function.

NXC coding philosophy question: I have a 4 line macro. One of the lines calls a subroutine. The subroutine has 1 local variable, 3 lines of C, and 3 lines of asm. What do I do with the subroutine - a) include it in the macro; b) make it inline; or c) make it a safecall. I think a) and b) wind up generating exactly the same amount of code inline. c) has less total code, but involves the additional overhead of: 1) the safecall mutex, 2) handing 5 parameters (one of which is a string) from the macro into the sub. As an ex-performance analyst, I'm torn between them.

OK, fire away.

Edit: I decided to see what it would look like all mashed into the macro. I wound up with 5 lines of C and 2 asm lines. In doing the mashup, I realized that the local variable wasn't needed (I took the input data directly into the inner data structure). I saved a couple of expensive lines of source.

[mattallen37]

It's a trade-off between execution speed and program size. Normally my programs aren't very limited by either (speed or size), so I use whatever I fell like using.

[mcsummation]

I made the macro handle the mutex issue.

However, I have another thing now:

Code: Select all

struct a {
    string b;
    string c[];
};
a aa;
string d[];
string e;
long l;
task main() {
e = FlattenVar(l); // This works.
d[0] = FlattenVar(l); // So does this.
aa.b  = FlattenVar(l);  // And, yet again, it works.
aa.c[0] = e; // This doesn't work.
aa.c[0] = FlattenVar(l);  // Neither does this.
}

Why don't the last two work? The next to the last says "Data types are not compatible". The last one gives that plus a couple of other errors which would be secondary issues.