Re: [Ql-Users] sBASIC overloading...

2018-06-29 Thread pjwitte via Ql-Users

On 28/06/2018 09:03, Wolfgang Lenerz via Ql-Users wrote:

Hi,

I made a small Sbasic testcase (SMSQE, not QDOS).

I made a program with procedures all called "abcdefghijklmnopqrt"+ a 5
digit number at the end.

The program starts at line 100, is increased by one and very 12th line a
new 10 line procedure is created. The first statement therein is
"return", so that I don't meausre the body of the procedure. The rest of
the lines on the procdure are filled with "Print".

(so
100 def proc abcdefghijklmnopqrt00100
101 return
102 print
...
110 print
111 end def
112 def proc abcdefghijklmnopqrt00112

etc, until just after line 3.

The last procedure then is always

31000 def proc abcdefghijklmnopqrt31000

I then measured how long it takes to call the first procedure and the
last procedure.

Measured with the millisecond timer of SMSQmulator:

calling the fist procedure 1 million times takes 5742 milliseconds
calling the last procedure 1 million times takes 5768 milliseconds

Strange. I wonder whats eating the 26 nanoseconds..
Per
___
QL-Users Mailing List


Re: [Ql-Users] sBASIC overloading...

2018-06-28 Thread Dave Park via Ql-Users
I think it depends on which types of variables you're coercing...

In this case, because integers are stored as floats and are a wicked lie,
ints and floats are already the same thing logically speaking. So the only
invalid coercion is string to float where the string contents are of the
wrong type.

I wonder the history behind the shortcut?

On Thu, Jun 28, 2018 at 1:01 AM, Wolfgang Lenerz via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi,
>
> I can't help but wonder whether the time taken to parse all your
> parameters to check whether they are the right type won't be longer than
> having several procedures.
>
> Wolfgang
>
>
>
> > I'll make sure to respond right away in future, before I've fully
> > understood the subtleties and implications of your replies. :D
> >
> > I was digesting the reply. I've been neck deep in developing a USB
> keyboard
> > solution for the QL - a project that has become a multi-headed beast that
> > required getting into elements of the 8302/8049 relationship I just never
> > knew I'd have to think about. Also neck deep in fence building after a
> > neigborhood dog broke into the pen and killed many of my chickens.
> >
> > It does seem that coercion gives similar results - if everything is
> passed
> > as a string, it can be coerced however we'd like, as long as the data is
> > checked for validity.
> >
> > It does seem the functionality of overloading can be implemented in
> > roundabout yet still brief and readable ways.
> >
> > Thank you.
> >
> >
> >
> > On Tue, Jun 26, 2018 at 1:57 PM, Per Witte via Ql-Users <
> > ql-users@lists.q-v-d.com> wrote:
> >
> >> So sorry for wasting my time trying to answer your question. It wont
> happen
> >> again.
> >>
> >> On 21 June 2018 at 16:38, Per Witte  wrote:
> >>
> >>> Im not familiar with C++ overloading, but S*BASIC allows some
> "parametric
> >>> polymorphism", viz:
> >>>
> >>> dim x%(2): for i% = 0 to 2: x%(i%) = 9 - i%
> >>> Test 'abc', 2.99, x%
> >>> :
> >>> def proc Test(a, b%, c)
> >>> print a\ b% \ c, \
> >>> enddef Test
> >>> :
> >>> Result:
> >>> abc
> >>> 2.99
> >>> 9  8  7
> >>>
> >>> The SBASIC compiler performs a number of additional passes to
> >> SuperBASIC's
> >>> parser, to end up with a much purer "executable". The compiled program
> is
> >>> not machine code, of course, it consists of fixed length tokens that
> >> still
> >>> need to be "interpreted". But all useless baggage has been eliminated
> >> from
> >>> the program flow, expressions teased into simple RPN steps, and
> locations
> >>> resolved to absolute addresses. So no, the size of the program or
> >> distance
> >>> to procedures does not effect the speed of execution.
> >>>
> >>>
> >>> On 20 June 2018 at 22:35, Dave Park via Ql-Users <
> >> ql-users@lists.q-v-d.com
>  wrote:
> >>>
>  Hi all,
> 
>  How hard would it be to extend sBASIC functions to support C++ style
>  overloading?
> 
>  Separately, does the sBASIC in SMSQ or Minerva still scan for
>  procedures/functions from the beginning of the program, so earlier
>  FN/PROCs
>  have a speed advantage over later ones like in JM/JS?
> 
> 
>  --
>  Dave Park
>  d...@sinclairql.com
>  ___
>  QL-Users Mailing List
> 
> 
> >>>
> >> ___
> >> QL-Users Mailing List
> >>
> >
> >
> >
> ___
> QL-Users Mailing List
>



-- 
Dave Park
d...@sinclairql.com
___
QL-Users Mailing List


Re: [Ql-Users] sBASIC overloading...

2018-06-28 Thread Wolfgang Lenerz via Ql-Users
Hi,

I made a small Sbasic testcase (SMSQE, not QDOS).

I made a program with procedures all called "abcdefghijklmnopqrt"+ a 5
digit number at the end.

The program starts at line 100, is increased by one and very 12th line a
new 10 line procedure is created. The first statement therein is
"return", so that I don't meausre the body of the procedure. The rest of
the lines on the procdure are filled with "Print".

(so
100 def proc abcdefghijklmnopqrt00100
101 return
102 print
...
110 print
111 end def
112 def proc abcdefghijklmnopqrt00112

etc, until just after line 3.

The last procedure then is always

31000 def proc abcdefghijklmnopqrt31000

I then measured how long it takes to call the first procedure and the
last procedure.

Measured with the millisecond timer of SMSQmulator:

calling the fist procedure 1 million times takes 5742 milliseconds
calling the last procedure 1 million times takes 5768 milliseconds

Wolfgang








> 
> I can't help but wonder whether the time taken to parse all your
> parameters to check whether they are the right type won't be longer than
> having several procedures.
> 
> Wolfgang
> 
> 
> 
>> I'll make sure to respond right away in future, before I've fully
>> understood the subtleties and implications of your replies. :D
>>
>> I was digesting the reply. I've been neck deep in developing a USB keyboard
>> solution for the QL - a project that has become a multi-headed beast that
>> required getting into elements of the 8302/8049 relationship I just never
>> knew I'd have to think about. Also neck deep in fence building after a
>> neigborhood dog broke into the pen and killed many of my chickens.
>>
>> It does seem that coercion gives similar results - if everything is passed
>> as a string, it can be coerced however we'd like, as long as the data is
>> checked for validity.
>>
>> It does seem the functionality of overloading can be implemented in
>> roundabout yet still brief and readable ways.
>>
>> Thank you.
>>
>>
>>
>> On Tue, Jun 26, 2018 at 1:57 PM, Per Witte via Ql-Users <
>> ql-users@lists.q-v-d.com> wrote:
>>
>>> So sorry for wasting my time trying to answer your question. It wont happen
>>> again.
>>>
>>> On 21 June 2018 at 16:38, Per Witte  wrote:
>>>
 Im not familiar with C++ overloading, but S*BASIC allows some "parametric
 polymorphism", viz:

 dim x%(2): for i% = 0 to 2: x%(i%) = 9 - i%
 Test 'abc', 2.99, x%
 :
 def proc Test(a, b%, c)
 print a\ b% \ c, \
 enddef Test
 :
 Result:
 abc
 2.99
 9  8  7

 The SBASIC compiler performs a number of additional passes to
>>> SuperBASIC's
 parser, to end up with a much purer "executable". The compiled program is
 not machine code, of course, it consists of fixed length tokens that
>>> still
 need to be "interpreted". But all useless baggage has been eliminated
>>> from
 the program flow, expressions teased into simple RPN steps, and locations
 resolved to absolute addresses. So no, the size of the program or
>>> distance
 to procedures does not effect the speed of execution.


 On 20 June 2018 at 22:35, Dave Park via Ql-Users <
>>> ql-users@lists.q-v-d.com
> wrote:

> Hi all,
>
> How hard would it be to extend sBASIC functions to support C++ style
> overloading?
>
> Separately, does the sBASIC in SMSQ or Minerva still scan for
> procedures/functions from the beginning of the program, so earlier
> FN/PROCs
> have a speed advantage over later ones like in JM/JS?
>
>
> --
> Dave Park
> d...@sinclairql.com
> ___
> QL-Users Mailing List
>
>

>>> ___
>>> QL-Users Mailing List
>>>
>>
>>
>>
> ___
> QL-Users Mailing List
> 
> 
___
QL-Users Mailing List


Re: [Ql-Users] sBASIC overloading...

2018-06-28 Thread Wolfgang Lenerz via Ql-Users
Hi,

I can't help but wonder whether the time taken to parse all your
parameters to check whether they are the right type won't be longer than
having several procedures.

Wolfgang



> I'll make sure to respond right away in future, before I've fully
> understood the subtleties and implications of your replies. :D
> 
> I was digesting the reply. I've been neck deep in developing a USB keyboard
> solution for the QL - a project that has become a multi-headed beast that
> required getting into elements of the 8302/8049 relationship I just never
> knew I'd have to think about. Also neck deep in fence building after a
> neigborhood dog broke into the pen and killed many of my chickens.
> 
> It does seem that coercion gives similar results - if everything is passed
> as a string, it can be coerced however we'd like, as long as the data is
> checked for validity.
> 
> It does seem the functionality of overloading can be implemented in
> roundabout yet still brief and readable ways.
> 
> Thank you.
> 
> 
> 
> On Tue, Jun 26, 2018 at 1:57 PM, Per Witte via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
> 
>> So sorry for wasting my time trying to answer your question. It wont happen
>> again.
>>
>> On 21 June 2018 at 16:38, Per Witte  wrote:
>>
>>> Im not familiar with C++ overloading, but S*BASIC allows some "parametric
>>> polymorphism", viz:
>>>
>>> dim x%(2): for i% = 0 to 2: x%(i%) = 9 - i%
>>> Test 'abc', 2.99, x%
>>> :
>>> def proc Test(a, b%, c)
>>> print a\ b% \ c, \
>>> enddef Test
>>> :
>>> Result:
>>> abc
>>> 2.99
>>> 9  8  7
>>>
>>> The SBASIC compiler performs a number of additional passes to
>> SuperBASIC's
>>> parser, to end up with a much purer "executable". The compiled program is
>>> not machine code, of course, it consists of fixed length tokens that
>> still
>>> need to be "interpreted". But all useless baggage has been eliminated
>> from
>>> the program flow, expressions teased into simple RPN steps, and locations
>>> resolved to absolute addresses. So no, the size of the program or
>> distance
>>> to procedures does not effect the speed of execution.
>>>
>>>
>>> On 20 June 2018 at 22:35, Dave Park via Ql-Users <
>> ql-users@lists.q-v-d.com
 wrote:
>>>
 Hi all,

 How hard would it be to extend sBASIC functions to support C++ style
 overloading?

 Separately, does the sBASIC in SMSQ or Minerva still scan for
 procedures/functions from the beginning of the program, so earlier
 FN/PROCs
 have a speed advantage over later ones like in JM/JS?


 --
 Dave Park
 d...@sinclairql.com
 ___
 QL-Users Mailing List


>>>
>> ___
>> QL-Users Mailing List
>>
> 
> 
> 
___
QL-Users Mailing List


Re: [Ql-Users] sBASIC overloading...

2018-06-21 Thread Per Witte via Ql-Users
Im not familiar with C++ overloading, but S*BASIC allows some "parametric
polymorphism", viz:

dim x%(2): for i% = 0 to 2: x%(i%) = 9 - i%
Test 'abc', 2.99, x%
:
def proc Test(a, b%, c)
print a\ b% \ c, \
enddef Test
:
Result:
abc
2.99
9  8  7

The SBASIC compiler performs a number of additional passes to SuperBASIC's
parser, to end up with a much purer "executable". The compiled program is
not machine code, of course, it consists of fixed length tokens that still
need to be "interpreted". But all useless baggage has been eliminated from
the program flow, expressions teased into simple RPN steps, and locations
resolved to absolute addresses. So no, the size of the program or distance
to procedures does not effect the speed of execution.


On 20 June 2018 at 22:35, Dave Park via Ql-Users 
wrote:

> Hi all,
>
> How hard would it be to extend sBASIC functions to support C++ style
> overloading?
>
> Separately, does the sBASIC in SMSQ or Minerva still scan for
> procedures/functions from the beginning of the program, so earlier FN/PROCs
> have a speed advantage over later ones like in JM/JS?
>
>
> --
> Dave Park
> d...@sinclairql.com
> ___
> QL-Users Mailing List
>
>
___
QL-Users Mailing List


Re: [Ql-Users] sBASIC overloading...

2018-06-21 Thread Jan Bredenbeek via Ql-Users
On 21 June 2018 at 15:21, Dave Park via Ql-Users 
wrote:

> > SuperBASIC is quite unique in that it stores the *difference* in length
> of
> > a line compared to the previous line, along with its line number. This
> way,
> > because the current line length is also stored in a system variable, it
> can
> > search for lines in both backward and forward direction. So a proc/fn
> call
> > will be faster when the definition is closer to the calling line. This is
> > also mentioned in the Minerva documentation.
>
> ​Hmmm. Are they stored in a known order, eg: alphabetical or order of
> creation/declaration
>

They are stored in order of line number (it's Basic, after all...).


> > You cannot define a proc/fn multiple times but you can check the type and
> > usage of a parameter using the PARTYP, PARUSE, PARNAM$ and PARSTR$
> > functions in TK2 and act accordingly. An example of this is in my 'ls'
> > procedure which uses an extra parameter as a flag for recursive directory
> > searches. When this parameter is empty it only lists the current
> directory.
>
> ​I suppose it does reduce these stresses that while sBASIC has "strict"
> typing of variables, it allows easy transfer between variable types.​ It
> also has the concepts of undefined variables and defined but unset
> variables.
>

It's not as strict as it seems. What's also unique in S*BASIC is
'coercion'. You want to assign a numeric value to a string variable and
S*BASIC will happily do this, by converting the number to a string (in
other BASICs you would have to use STR$). And the other way round assign a
string value to a numeric variable (provided the string contains a valid
number).
The type of a parameter in a procedure or function is determined when the
function is *called*, not when it's defined. In a machinecode function you
can find out what type a parameter is and choose to evaluate it as a
number, string or name (in a BASIC function you can use the four TK2
functions mentioned above though you're probably a bit more restricted by
parameter types).
Also, variables are never undefined (they're defined as soon as you enter
their name in a program line) but they can be unset...


> Quite amazing for a language that fit in a very small part of 48K.


 And all written in 68K assembler in a few weeks time...

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

Re: [Ql-Users] sBASIC overloading...

2018-06-21 Thread Dave Park via Ql-Users
On Thu, Jun 21, 2018 at 3:13 AM, Jan Bredenbeek via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> SuperBASIC is quite unique in that it stores the *difference* in length of
> a line compared to the previous line, along with its line number. This way,
> because the current line length is also stored in a system variable, it can
> search for lines in both backward and forward direction. So a proc/fn call
> will be faster when the definition is closer to the calling line. This is
> also mentioned in the Minerva documentation.


​Hmmm. Are they stored in a known order, eg: alphabetical or order of
creation/declaration


> You cannot define a proc/fn multiple times but you can check the type and
> usage of a parameter using the PARTYP, PARUSE, PARNAM$ and PARSTR$
> functions in TK2 and act accordingly. An example of this is in my 'ls'
> procedure which uses an extra parameter as a flag for recursive directory
> searches. When this parameter is empty it only lists the current directory.


​I suppose it does reduce these stresses that while sBASIC has "strict"
typing of variables, it allows easy transfer between variable types.​ It
also has the concepts of undefined variables and defined but unset
variables.

Quite amazing for a language that fit in a very small part of 48K.


-- 
Dave Park
d...@sinclairql.com
___
QL-Users Mailing List

Re: [Ql-Users] sBASIC overloading...

2018-06-21 Thread Jan Bredenbeek via Ql-Users
On 21 June 2018 at 00:43, Dave Park via Ql-Users 
wrote:

> My reason for asking was, I was wondering if an analysis of how frequently
> functions were called, and from where, could affect how quickly they would
> be stepped to. I have seen this behavior in SuperBASIC on JM/JS and
> achieved often useful gains in improvements by placing the most frequently
> called functions at the beginning or the program.
>

SuperBASIC is quite unique in that it stores the *difference* in length of
a line compared to the previous line, along with its line number. This way,
because the current line length is also stored in a system variable, it can
search for lines in both backward and forward direction. So a proc/fn call
will be faster when the definition is closer to the calling line. This is
also mentioned in the Minerva documentation.


> I was wondering if this was still true with the BASIC on SMSQ/Minerva.
>

AFAIK, Minerva is not very different in the way data structures are stored
compared to Sinclair ROMs, but SMSQ is.


> That let to the overloading question, which would allow the collapsing of
> many functions into a single function using polymorphism.
>

You cannot define a proc/fn multiple times but you can check the type and
usage of a parameter using the PARTYP, PARUSE, PARNAM$ and PARSTR$
functions in TK2 and act accordingly. An example of this is in my 'ls'
procedure which uses an extra parameter as a flag for recursive directory
searches. When this parameter is empty it only lists the current directory.

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


Re: [Ql-Users] sBASIC overloading...

2018-06-20 Thread Dave Park via Ql-Users
My reason for asking was, I was wondering if an analysis of how frequently
functions were called, and from where, could affect how quickly they would
be stepped to. I have seen this behavior in SuperBASIC on JM/JS and
achieved often useful gains in improvements by placing the most frequently
called functions at the beginning or the program.

I was wondering if this was still true with the BASIC on SMSQ/Minerva.

That let to the overloading question, which would allow the collapsing of
many functions into a single function using polymorphism.

On Wed, Jun 20, 2018 at 5:10 PM, Jan Bredenbeek via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> On 20 June 2018 at 22:35, Dave Park via Ql-Users  >
> wrote:
>
> > Hi all,
> >
> > Separately, does the sBASIC in SMSQ or Minerva still scan for
> > procedures/functions from the beginning of the program, so earlier
> FN/PROCs
> > have a speed advantage over later ones like in JM/JS?
>
>
> SuperBASIC (JM/JS/Minerva) stores line numbers along with proc/fn names in
> the name table and can search backward and forward for them in the program.
> So it merely depends on how far away the proc/fn definition is from the
> calling code in terms of lines.
> I don't know how SBASIC handles this but as it is said to be more a
> compiler than an interpreter it could be very well different (the most
> efficient way would of course be to store addresses rather than line
> numbers but this could break if the program is changed and then
> CONTINUEd/RETRYd).
>
> Jan.
>
> --
> *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
> ___
> QL-Users Mailing List
>



-- 
Dave Park
d...@sinclairql.com
___
QL-Users Mailing List


Re: [Ql-Users] sBASIC overloading...

2018-06-20 Thread Jan Bredenbeek via Ql-Users
On 20 June 2018 at 22:35, Dave Park via Ql-Users 
wrote:

> Hi all,
>
> Separately, does the sBASIC in SMSQ or Minerva still scan for
> procedures/functions from the beginning of the program, so earlier FN/PROCs
> have a speed advantage over later ones like in JM/JS?


SuperBASIC (JM/JS/Minerva) stores line numbers along with proc/fn names in
the name table and can search backward and forward for them in the program.
So it merely depends on how far away the proc/fn definition is from the
calling code in terms of lines.
I don't know how SBASIC handles this but as it is said to be more a
compiler than an interpreter it could be very well different (the most
efficient way would of course be to store addresses rather than line
numbers but this could break if the program is changed and then
CONTINUEd/RETRYd).

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List


[Ql-Users] sBASIC overloading...

2018-06-20 Thread Dave Park via Ql-Users
Hi all,

How hard would it be to extend sBASIC functions to support C++ style
overloading?

Separately, does the sBASIC in SMSQ or Minerva still scan for
procedures/functions from the beginning of the program, so earlier FN/PROCs
have a speed advantage over later ones like in JM/JS?


-- 
Dave Park
d...@sinclairql.com
___
QL-Users Mailing List