Hi George,
I have downloaded the new Yurbo v4g21, I will try it on all my programs on the Q60, QXl, QPC2, Atari QL, Trump Card QL...
I would like you to keep in the backwards compatibility within Turbo, as there are still people using a QL that do not use SMSQ/E and GD2.
I think that the backwards compatabilty is important to support these users.
What is the minimum specification of QL that is required to use Turbo now.
Derek
[EMAIL PROTECTED] wrote:
In a message dated 30/04/05 16:37:59 GMT Daylight Time, [EMAIL PROTECTED] writes:
There is one more change that I have made. That is in the choice of stack size. EasyPtr and QPTR extensions need more stack than the 350 bytes
default. You <>
Could the problems I mentioned to you in a private mail (lots of inexplicable run-time errors) relate to this issue, do you think? I know, I could just try and figure it out for myself ;) but Im shortly going away for a week, and perhaps others are struggling with the same problem..
The effects of overwriting items in dataspce because the stack is too small are unpredictable. I have usually found that it is particularly hard to debug these programs. It is therefore a good idea to bear in mind that some S*BASIC extensions use much more stack than normal. This is true of QPTR and, I think, EasyPtr as well.
Incidentally I think it would a good idea if a register were available showing those extensions which needed a stack size of over, say, 250 bytes.
I have also looked at PEEK(!! etc) which allow easy access to system variables and (PEEK(\\ etc) which allow access to S*BASIC areas. PEEK and
POKE are
dealt internally by Turbo which is much faster than calling the rom
versions. It
would not be easy to allow for the !! and \\ variations.
However, the system variables is found at SYS_VARS so a slightly extended PEEK parameter can replace PEEK(!! . .). Also Turbo TK Code has several
BASIC_xxx
functions which should cover a lot od the PEEK(\\ ...) ground.
Im aware of SYS_VARS and BASIC_xxx, but Turbo is supposed to be a S*Basic compiler, not a language of its own (this is the nature of one of the arguments I had with Freddy, who appeared to be arguing that it was SuperBasic that was incompatible!)
I don't think it will ever be the case that Turbo can compile all programs written in S*BASIC. If that did come about I guess that the speed advantage would disappear and that it would be just as fast running the program in S*BASIC. PEEK and POKE are examples of this. Instead of calling the machine code Turbo does it internally. Since only two or three assembler instructions are needed this is much faster.
There are three areas where, at the moment, programs written to be compiled by Turbo are restricted.
1. DATA lines must contain just pure numbers or strings.
2. Variable names can't be used in different places with a different number of dimensions.
3. Some integer arithmetic requires careful handling. In some cases Turbo assumes that the result will be an integer where S*BASIC assumes floating point.
This shows that Turbo does not aim to compile ALL S*BASIC programs.
I understand that this could be a wee bit problematic, as these variants arent SuperBasic. However, Turbo is in a state of flux at the moment it might be an idea to lay a couple of DP issues to rest now. Afterall, much of the duplication in Turbo was to try to overcome some of the limitations in the original QDOS ROMs. Im thinking of things like EXECUTE_x and.. well, I can remember just now (Im in a bit of a hurry). The place to compensate for the differences between SBasic and SuperBasic is in their respective Turbo toolkit extenstions.
I would stringly advise against using EXECUTE_x. The reason is that as they stand they make no allowance for parameter strings. EX, EW etc all increase the dataspace to accommodate any parameter string supplied, and the length can be up to 32K. The EXECUTE_x instructions do not make that allowance. It is therefore possible to overwrite the compiled program and probably several neighbouring ones as well by :
a$=FILL$(" ",32000) EXECUTE_W;a$
So, why not get rid of EXECUTE_xx, BASIC_xx and all that and try to simplify
things by reducing the number of different ways of achieving the same thing?
Sbasic has some 400+ commands already! and Turbo_tk_code has 111 commands.
Many people only use about 2000 words in their daily communications, so this
combination might imply that learning Sbasic and Turbo is only about 25% as
difficult as learning an entirely new language. Probably not a meaningful
comparison, but you catch my drift?
I certainly would not want to throw away BASIC_xx becasue they are used in parser_task itself! I am not sure why having several extensions doing the same thing (or nearly the same thing) is to be avoided. In GWASS I have several different names for the same command. For example ENDIF and END_IF are exactly equivalent.
There has been much talk of maintaining backward compatibility with Qdos. Also, lowering the threshhold for any potential newcomers (fat chance!) would be great. Here is a chance of doing that.
I am a great believer in the need for backward compatibilty, provided it does not avoid the use of new facilities. For example Turbo has been altered to allow various kewywords using the GD2 colours to work but it still works also with AH, JM and JS roms.
The toolkit is something I would be willing to help with. (In fact I already
have written a toolkit or two to fill in some of the gaps between Qdos and
Smsqe.)
Any help is welcome. Dave Gilham is the person looking after Turbo Toolkit of course.
I hope soon to send out Turbo v4h21.
Bring it on!
I have sent it off for loading on the site today.
George
_______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
_______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
