RESTARTING in 68K Assembler for QDOS

Anything QL Software or Programming Related.
User avatar
tofro
Font of All Knowledge
Posts: 3115
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: RESTARTING in 68K Assembler for QDOS

Post by tofro »

janbredenbeek wrote:
If only S*BASIC would support pointers like C does... :(
It does. Kind of.

Item 2 in my post above basically boils down to something close to a pointer approach. It does, however, also involve complicated fiddling with the name table.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
ql_freak
Super Gold Card
Posts: 503
Joined: Sun Jan 18, 2015 1:29 am

Re: RESTARTING in 68K Assembler for QDOS

Post by ql_freak »

Hello Tobias,
tofro wrote:
  • Require your calling program to allocate the strings using DIM and pass that string into the MC procedure by reference - This is maybe the best approach. ... Such an approach does, however, rely on a valid name table structure and could thus not be compiled with Turbo (QLiberator would cope, though, I think). It might be a bit awkward to use, as you need to DIM a string before you can GETLINE$ a value into it, but I don't currently know a portable method to grow an S*Basic string in memory from an MC procedure.
This looks very interesting. Especially as I must not have a GETLINE$ function. I wanted it, because there is no FAST way to a read a single byte (char) in S*BASIC as e.g. getc() in C. I'm afraid INKEY$() always calls IO.FBYTE(), while getc() is buffered. So I perhaps write a fast (buffered) GETC() function which can e.g. be used with: DIM a$(32766): INIT_GETC(#chan,filepointer): FOR I=1 to 32766: tmp=GETC():if tmp<0: doOnError ELSE a$(i)=CHR$(tmp). Of course the programmer is then responsible for not issuing other IO-calls on #chan. This should also be compatible with Turbo.
tofro wrote:
  • Stay with your approach and allocate memory to the Ari stack in chunks of, e.g. 1024 bytes as you go. This can be relatively tedious and slow for long strings, as you'd have to move the whole string allocation maximum 32 times downwards when you re-allocate the target memory area for the growing string - And it would still duplicate memory: If you do a x$=GETLINE$, you need the memory for the string twice, once for the temporary return value on the arithmetic stack, the other for the target variable.
    target string in the assigned variable. This might look like a way to go at first but collects all the possible downsides of return value passing ;)
Yes this would work, but as I have written, is a horror to implement.
tofro wrote: Hope this helps,
Thank you.

Hello Jan,
janbredenbeek wrote: If the string is very long you'll end up with a big S*BASIC buffer which will not be released, even not after a NEW (at least on JS, Minerva is better behaved in this respect). Note that on JM and earlier there is no provision for strings longer than the buffer size, you just get a 'buffer full' error when trying to read more characters than fit in the buffer (128 bytes after switch-on)!
Oops, I didn't know that, thank you.
janbredenbeek wrote: If only S*BASIC would support pointers like C does... :(
A fast (buffered) S*BASIC function to read one byte (char) would also help. I will think about yours and Tobias suggestions, what best suits my needs.

Peter


http://peter-sulzer.bplaced.net
GERMAN! QL-Download page also available in English: GETLINE$() function, UNIX-like "ls" command, improved DIY-Toolkit function EDLINE$ - All with source. AND a good Python 3 Tutorial (German) for Win/UNIX :-)
Post Reply