Misc Notes

pjc30943 · Post by **pjc30943** » 04 December 2005, 10:21 AM

Hi Don,
Two comments:

(1)
"ExitTask" is not syntax-highlighted, though it should be.

(2)
Do Until <variable = TRUE> does not seem to function.

However, Do Loop, and Do Loop Until <Exp> do work fine.

spamiam · Post by **spamiam** » 04 December 2005, 11:17 AM

I am sure you already did this.... but is the variable Boolean?

I find this one item in BASIC a little annoying. In C, which I use more often, anything other than zero is "TRUE". I end up checking if a variable is <> 0 instead of converting to a boolean and then checking against TRUE.
I am not sure which technique is faster to execute, but it can not be too different given the type conversion.

-Tony

mikep · Post by **mikep** » 04 December 2005, 11:29 AM

ExistTask is not a ZBasic keyword. It is a system library function and is therefore not highlighted.

Mike
http://home.austin.rr.com/perks/micros/

pjc30943 · Post by **pjc30943** » 04 December 2005, 11:46 AM

spamiam wrote:I am sure you already did this.... but is the variable Boolean?

I find this one item in BASIC a little annoying. In C, which I use more often, anything other than zero is "TRUE". I end up checking if a variable is <> 0 instead of converting to a boolean and then checking against TRUE.
I am not sure which technique is faster to execute, but it can not be too different given the type conversion.

-Tony

Thanks for the thought. Yes, it is boolean.

Do until <.. = TRUE>
Loop

does not work, but

Do
Loop until <.. = TRUE>

does work, with the same expression in both. There can be no change jumping from the "Loop" back up to the "Do", so both should exit at some point, except that one runs for an extra cycle. Yet the top one never exits, the bottom works fine. I can debug the state of the expression from inside the loop, and it eventually shows TRUE in both cases; one goes on indefinitely.
I'm checking the timeout variable of GetQueue inside the loop: I pull in data until there is none left, in which case TimeOut= TRUE.

No one else has had issues with this? I guess it's just me

pjc30943 · Post by **pjc30943** » 04 December 2005, 11:48 AM

mikep wrote:ExistTask is not a ZBasic keyword. It is a system library function and is therefore not highlighted.

Mike

Okay, thanks. So CallTask is a keyword, ExitTask is not. Aren't both system library functions? This is not really important of course...

mikep · Post by **mikep** » 04 December 2005, 14:59 PM

This is really a message for Don.

In the Language Reference Manual, CallTask is referred to as a statement. In the System Library Reference Manual it is referred to as special purpose along with Debug.Print. Also Console.Write and Console.WriteLine are referred to as methods. However there is some inconsistent formatting in the IDE:

CallTask - not a keyword but listed as a keyword in Appendix A.
Console.Read - Read is a keyword. Console is not a keyword and is not listed in Appendix A
Console.ReadLine - ReadLine is not a keyword
Console.Write - Write is a keyword and listed as a keyword in Appendix A
Console.WriteLine - WriteLine is not a keyword
Debug.Print - Debug and Print are both keywords but only Print listed in Appendix A
Register by itself is a keyword, listed in Appendix A
Register.ACSR - neither are keywords and ACSR is not listed in Appendix A

Although I'm not sure I really care which things you make into keywords, providing that there is consistency between the IDE, Appendix A and the two reference manuals.

Post by **dkinzer** » 04 December 2005, 20:48 PM

I end up checking if a variable is <> 0 instead of converting to a boolean and then checking against TRUE

Note that these two constructions are equivalent:

Code: Select all

Dim b as Byte
If &#40;CBool&#40;b&#41;&#41; Then
End If

If &#40;CBool&#40;b&#41; = true&#41; Then
End If

The compiler treats them the same (i.e. the same code is generated) if optimization is on. With optimization off, the second one will generate more code to do the same thing. You can verify this by looking at the listing file.

Similarly, these are equivalent:

Code: Select all

Dim b as Byte
If &#40;Not CBool&#40;b&#41;&#41; Then
End If

If &#40;CBool&#40;b&#41; <> true&#41; Then
End If

In this case, if optimization is on the compiler generates code for testing the opposite sense; the resulting code is the same number of bytes as the case above.

Currently, this source code results in more code generated for the same result.

Code: Select all

Dim b as Byte
If &#40;b <> 0&#41; Then
End If

This is a situation where an (obvious, in retrospect) optimization was overlooked. It's on the list of things to add. When this optimization is added, the generated code will be identical to the equivalent cases above.

If you want the compiler to generate a listing that has mixed source and object code, add this line to your .pjt file:

Code: Select all

--list=filename.lst

Replace filename.lst with the name you want for the listing file. The meaning of most of the pcode instructions should be clear from the context. A document describing all of the instructions is planned.

Also, the problem with the Do Until has been confirmed, identified and resolved. As a side note, that would have been better as a separate post since it has to do with the compiler not the IDE.

Post by **dkinzer** » 04 December 2005, 21:11 PM

So CallTask is a keyword, ExitTask is not. Aren't both system library functions?

You may have noticed that CallTask is syntactically different from Call. I don't know why NetMedia chose the syntax that they did. It seems to me that the syntax ought to be similar, e.g.

Code: Select all

CallTask taskName&#40;taskStack&#41;

Alas, such is not the case so we're left with Call and CallTask being keywords, having similar functions, but having dissimilar syntax. C'est la vie.

The System Library comprises a set of procedures invoked in a fashion similar to the way that user procedures are invoked. The biggest difference between System Library procedures and user-written procedures is the polymorphic characteristics of some of the System Library procedures with respect to parameter types.

Mike has pointed out some inconsistencies in the documentation with regard to nomenclature. These issues will be addressed. One thing to note is that Debug.Print is actually one keyword, not two. It is not listed in Appendix A because there is no possibility of conflict with user's identifiers since you can't create an identifier with a period in it. Print is in the reserved word list (I assume) because it has historically been a keyword in Basic dialects.

The same is true for Read and Write, their presence is not due to the existence of the difficult-to-classify Console.Read and Console.Write. These "methods" were introduced in Visual Basic along with some object oriented features. Of course, ZBasic doesn't have any object oriented features but the syntax of Debug.Print, Console.Read, and Register.PortC suggests that it does.

The reserved word list contains words that have historically been part of Basic (perhaps as early as Dartmouth Basic) even though they might not be keywords in Visual Basic, BasicX or ZBasic.

spamiam · Post by **spamiam** » 05 December 2005, 12:39 PM

No one else has had issues with this? I guess it's just me

Well, I'd not expect it is just you with such a simple statement as do...loop stuff.

I have used it both ways (I think) with no specific problems, It all depends on whether I want the loop executed at least once or not.

Usually I use "while" instead of "until". I think you would just invert the logic, no?

If you are having trouble with the "until", try it with "while" using just the minimal code to show the error, and then show how it works with "until", then give it to Don, he can then analyse it. He is really fast in showing me the holes in my logic.

Those whiles and untils are particularly prone to infinite loops when I have a brain freeze about the truth tables of the logic.

-Tony

Post by **dkinzer** » 05 December 2005, 16:28 PM

If you are having trouble with the "until", try it with "while"...

Actually, the compiler handles Do Until exactly like Do While except that the sense of the test is inverted. Consequently, coding it the other way produces exactly the same result.

The correction for the error was fairly simple. We just need to confirm it through the test suite to make sure no regression errors were introduced.

pjc30943 · Post by **pjc30943** » 16 January 2006, 15:00 PM

Just wondering: has the do..loop issue been corrected? I don't see it raised anywhere in the revision history, and it would be nice to not have to remember this issue when coding

Post by **dkinzer** » 16 January 2006, 15:55 PM

... has the do..loop issue been corrected?

Yes. It is the last item listed in the change notes in the update announcement.