Super newbie C questions

[arnljot]

Okay

These are stupid questions. But I'm reading up on Amiga programming and ANSI C, and I'm reading this tutorial:
http://www.liquido2.com/tutorial/

Now question 1:
In part 4 (http://www.liquido2.com/tutorial/draw.html)

Line 132 states:
window_signal = 1L << MyWindow->UserPort->mp_SigBit;

I understand this that he is copying the signal address of the window he's created into a varialbe called "window_signal".

What I don't understand is why he has to bitshift it to the left.

Tutorial says:
MyWindow->UserPort->mp_SigBit holds the number of the particular bit used to represent the message signal for MyWindow.  So, if MyWindow->UserPort->mp_SigBit happens to be 26, then we will shift the 1 to the left 26 places:

00000010 00000000 00000000 00000000

thus, the decimal value of window_signal would be 33,554,432.  That really doesn't matter here, because we're interested in the bit number much more than the value, but it may be useful to understand what's really going on.  Just remember that the signal bit for your window may be any number.

Why could he not just use:

Arnjots question:
window_signal = MyWindow->UserPort->mp_SigBit;

Isn't the bitshifting redundant? Or is it so that the name mp_SigBit is to be read literally, that its not the value it would be wih the bit set, but the digit position of the bit?

Next question:
Reading the code in the tutorial:

Line 139 to 142:
signals = Wait( window_signal );

/* Check the signal bit for our message port. Will be true if these is a message. */
if ( signals & window_signal )

Why is he using the AND bit operator here? What can Wait return? can the result of Wait be more than what you've "asked for" in the argument to Wait?

And if so, why would you ignore a return signal where the signal you are listening for is part of the bitmask?

I understand that my questions are a mix of lack of understanding of ANSI C, the Amiga Signaling system and the spesific application domain in this tutorial example.

I'm a bit embarresed to ask, but I wanna learn and understand the smallest details. And I'm starting on zero.

Please be gentle...

[koaftder]

It's called e-penis. Sorry, there's no other way to explain it. Keeps the code short, it's a magic cookie, it gets people fired in situations where code has to be audited.

[Tension]

I`ve always wondered why that was.

[SamuraiCrow]

1L<
The reason it is shifted is that each bit represents a unique flag, IIRC, so you can have as many as 32 unique flags.

[koaftder]

SamuraiCrow wrote:
1L<
The reason it is shifted is that each bit represents a unique flag, IIRC, so you can have as many as 32 unique flags.

Depends on the compiler.

[SamuraiCrow]

On any compiler for the Classic Amiga, it is much faster AFAIK.

[koaftder]

SamuraiCrow wrote:
On any compiler for the Classic Amiga, it is much faster AFAIK.

You're probably right.

[arnljot]

SamuraiCrow wrote:
The reason it is shifted is that each bit represents a unique flag, IIRC, so you can have as many as 32 unique flags.

So it is like I suspected, UserPort->mp_SigBit is literal.

And he uses the AND bit operator on the bitmask of the signal because if he OR'ed it he would get TRUE also if he wasn't listening for it, but it was set in the value he was testing on (I just realised this).

But what can the Wait function return when you haven't given it an OR'ed list of signals you're waiting on, but just one single signal.

[Piru]

But what can the Wait function return when you haven't given it an OR'ed list of signals you're waiting on, but just one single signal.

Obviously it will only return when this single signal is received, and return the signalmask set.

However, it is a bad idea to optimize such cases, because it will break horribly if you later add more signals. Keeping the style consistent regardless of the number of signals waited reduces the chance of unintended mistake.

[Tension]

Indeed.

[arnljot]

Ah, thanks.

I think I get it now. Now, I'd like to find a book or net articles on good C coding practices on the Amiga.

[davideo]

arnljot wrote:
Ah, thanks.

I think I get it now. Now, I'd like to find a book or net articles on good C coding practices on the Amiga.

I don't know about good or bad but there's a bit of information here http://www.amigacoding.com/index.php/C:Resources

Dave G  8-)

[Sidewinder]

Line 132 states:
window_signal = 1L << MyWindow->UserPort->mp_SigBit;

This is right out of the RKM.  I personally think it's ugly, but does anyone have another method that isn't equally ugly?

So it is like I suspected, UserPort->mp_SigBit is literal.

And he uses the AND bit operator on the bitmask of the signal because if he OR'ed it he would get TRUE also if he wasn't listening for it, but it was set in the value he was testing on (I just realised this).

I'm glad it's making more sense now.  Was the text confusing in some way?  Is there another way I could explain in the tutorial that would be more clear?

But what can the Wait function return when you haven't given it an OR'ed list of signals you're waiting on, but just one single signal.

Like Piru said, in this case the AND is redundant because Wait() only returns one signal.  But if you added another window, then your input signal mask to Wait() would have two bits set and you'd need to AND the result of Wait() against each window's signal mask to determine which window signaled.

I think I get it now. Now, I'd like to find a book or net articles on good C coding practices on the Amiga.

Well, there is a lot of old/bad example code out there.  For this tutorial I attempt to use an ANSI C style while following the RKMs as much as possible.  Not that the RKMs are the definitive guide to Amiga coding style either...but I digress.

[blanning]

Line 132 states:
window_signal = 1L << MyWindow->UserPort->mp_SigBit;

What I don't understand is why he has to bitshift it to the left.
MyWindow->UserPort->mp_SigBit holds the number of the particular bit used to represent the message signal for MyWindow.  So, if MyWindow->UserPort->mp_SigBit happens to be 26, then we will shift the 1 to the left 26 places:

00000010 00000000 00000000 00000000

Why could he not just use:

window_signal = MyWindow->UserPort->mp_SigBit;

If mp_SigBit were 3, the shift code would produce this:
....  00001000

but if you just assigned 3 to window_signal, you would get this:

.... 00000011

It's a one-liner that sets an individual bit to 1.

... that its not the value it would be wih the bit set, but the digit position of the bit?

that's it.

Line 139 to 142:
signals = Wait( window_signal );

/* Check the signal bit for our message port. Will be true if these is a message. */
if ( signals & window_signal )

Why is he using the AND bit operator here?

And is a quick and easy way to filter out what you want.  You can use it to test a single bit in a bitfield.

If signals contained 01010101 and you wanted to check the third one from the right, you can do this:

01010101 &
00000100 =
00000100

If the answer is non-zero, then your bit is set, otherwise, it's not set.  You'll frequently see this sort of thing as a series of #defines in an include somewhere with the 00000100 declared as a hex value 0x4 in this case.  I've also seen the shift operators used in those #defines as well.

brian

[arnljot]

Sidewinder wrote:
I'm glad it's making more sense now.  Was the text confusing in some way?  Is there another way I could explain in the tutorial that would be more clear?

Nah, I think it's fine the way it is. But perhaps it's because I get it now

But people are different, and will be stumped by different aspects.

At work we call it a "Bunny problem", after a coworker who had a stuffed bunny in his office. He could solve most problems by describing the problem to the stuffed bunny.

IBM im Norway had similar tactics with their customers, all customers had to give a detailed description of their problem to the lady in the reception, and if they still had a problem after describing it to the receptionist then they would get help. But most didn't as they realized what was wrong by "talking aloud" about the problem.

That was how I realized why you OR when you "select", and why you AND when you test.