|
|
| Author |
Message |
pjc30943
Joined: 02 Dec 2005
Posts: 220
|
|
Posted: 04 December 2005, 18:21 PM Post subject: Misc Notes |
 |
|
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. |
|
| Back to top |
|
 |
spamiam
Joined: 13 Nov 2005
Posts: 689
|
|
Posted: 04 December 2005, 19:17 PM Post subject: |
|
|
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 |
|
| Back to top |
|
|
mikep
Joined: 24 Sep 2005
Posts: 771
Location: Austin, TX
|
|
Posted: 04 December 2005, 19:29 PM Post subject: |
|
|
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/
Last edited by mikep on 04 December 2005, 22:33 PM; edited 1 time in total |
|
| Back to top |
|
|
pjc30943
Joined: 02 Dec 2005
Posts: 220
|
|
Posted: 04 December 2005, 19:46 PM Post subject: |
|
|
| 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  |
|
| Back to top |
|
|
pjc30943
Joined: 02 Dec 2005
Posts: 220
|
|
Posted: 04 December 2005, 19:48 PM Post subject: |
|
|
| 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... |
|
| Back to top |
|
|
mikep
Joined: 24 Sep 2005
Posts: 771
Location: Austin, TX
|
|
Posted: 04 December 2005, 22:59 PM Post subject: |
|
|
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. |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Posts: 2593
Location: Portland, OR
|
|
Posted: 05 December 2005, 4:48 AM Post subject: |
|
|
| Quote: | | 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: | Dim b as Byte
If (CBool(b)) Then
End If
If (CBool(b) = true) 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: | Dim b as Byte
If (Not CBool(b)) Then
End If
If (CBool(b) <> true) 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: | Dim b as Byte
If (b <> 0) 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: | | --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. |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Posts: 2593
Location: Portland, OR
|
|
Posted: 05 December 2005, 5:11 AM Post subject: |
|
|
| Quote: | | 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: | | CallTask taskName(taskStack) |
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. |
|
| Back to top |
|
|
spamiam
Joined: 13 Nov 2005
Posts: 689
|
|
Posted: 05 December 2005, 20:39 PM Post subject: |
|
|
| Quote: | | 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 |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Posts: 2593
Location: Portland, OR
|
|
Posted: 06 December 2005, 0:28 AM Post subject: |
|
|
| Quote: | | 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. |
|
| Back to top |
|
|
pjc30943
Joined: 02 Dec 2005
Posts: 220
|
|
Posted: 16 January 2006, 23:00 PM Post subject: |
|
|
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  |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Posts: 2593
Location: Portland, OR
|
|
Posted: 16 January 2006, 23:55 PM Post subject: |
|
|
| Quote: | | ... has the do..loop issue been corrected? |
Yes. It is the last item listed in the change notes in the update announcement. |
|
| Back to top |
|
|
|
ZBasic Home
Forum Rules
Memberlist
Usergroups
RSS Feed
Site Search
Links
Download
Digests and Subscriptions
Profile
Log in to check your private messages
Log in
Register