My head hurts ;-)

Oddly enough, explicitly typing variables (e.g. A%) actually slows things
down a bit.

And yes, the intermediate values can be >32767 as long as the result is a
legal integer.

m

On Sat, Oct 29, 2022 at 10:20 PM Eric LK <[email protected]> wrote:

> I wrote:
> >FWIW, I also tried "caching" the result of "PEEK(P+1)" but again,
> >it didn't change the result (in all 3 implementations, 1000
> >iterations took 14 seconds, so those modifications aren't really
> >interesting, except for the brain picking exercise ;o)).
>
> Well, I managed to (almost) half this time :o) : 8 seconds for 1000
> iterations!
>
> I'd like to say I found a very innovative solution, but it's so simple
> I wonder how we didn't think of it before... Just let the BASIC do the
> work for you :o)
>
> 10 DEFINTP-Q:DEFSTRH
> 20 H=CHR$(201)
> 30 P=VARPTR(H)+1:Q=VARPTR(P)
> 1000 POKE Q,PEEK(P):POKE Q+1,PEEK(P+1)
> 1010 PRINTP
>
> "John R. Hogerhuis" <[email protected]> wrote:
> > As to type sigils on variables... Don't know how much it changes ram use
> > or execution time. Some! Maybe look at the tokenized output difference
> > for the space difference.
>
> Thanks, I may give it a try. BTW, is there a good documentation of the
> tokenized format (and of the variables encoding) for the M100? I
> learned a lot about the ZX-Spectrum BASIC by reading the user guide
> which gives a lot of implementation details about this, but I don't
> remember the M100 user manual going so deep.
>
> > If it goes over 32767 on any permutation of peek'd values it will fail.
> > Probably worth generating every permutation and confirming it
> > works.
>
> I suspect the integer conversion is only made when the value is stored
> in the integer variable.
> For example, this totally works:
> A%=1E15/1E14:?A%
>
> The only thing to be careful with is using functions that can only
> work with integer arguments like \ or AND:
> ?1E15\1E14 => OV Error
> ?!E15AND1E14 => OV Error
>
> Eric
>

Reply via email to