Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
Sorry wrong quotes ... It was for Marcel Il 11 apr 2017 17:23, "Ralf Reköndt" ha scritto: > Yes, I know. Although Marcel do not know, I would be interested in knowing > the way, they have realized it. > > Ralf > > Am 11.04.2017 um 12:07 schrieb Derek Stewart: > >> On 11/04/17 09:58, Ralf Reköndt wrote: >> >>> Yes, would be interesting to know, how QLib does this with its compiled >>> "resident" extensions. >>> >>> Ralf >>> >>> -Original-Nachricht- >>> Betreff: Re: [Ql-Users] Marcel has done it again - SMSQE 3.31 >>> Datum: 2017-04-11T10:47:36+0200 >>> Von: "Jan Bredenbeek" >>> >>> On 11 April 2017 at 10:07, Derek Stewart wrote: >>> >>> Hi Marcel, >>> >>>> >>>> Do you think it is possible for the SMSQ/E internal compiler produce a >>>> compiled version of the SBASIC programme? >>>> >>> >>> >>> You can EXEC a SBASIC program in the same way as a 'normal' executable >>> program on SMSQ/E (which actually starts another instance of SBASIC). >>> But the code produced by the real-time compiler is not real 68000 code >>> but >>> pseudo-code and needs the SBASIC environment to work. So it cannot be a >>> stand-alone EXECable program unless the SBASIC runtime environment also >>> comes with it. >>> Nevertheless it would be a great idea if you could write a procedure in >>> SBASIC and LRESPR the compiled code as SBASIC extension so you have it >>> always available. AFAIK there is no higher-level language compiler >>> capable >>> of producing SBASIC extensions - or perhaps Qliberator? >>> >>> Jan. >>> >>> Hi, >> >> Qliberator has a nice feature that S*Basic procedures and Functions can >> be compiled and loaded as Resident Procedures and Functions using the >> EXTERNAL for single Procedure or Function and EXT_ALL for all Procedures >> and Functions directives in REMark statements. >> >> Something like that would be nice to have built into SMSQ/E. >> >> > ___ > QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
Yes, I know. Although Marcel do not know, I would be interested in knowing the way, they have realized it. Ralf Am 11.04.2017 um 12:07 schrieb Derek Stewart: On 11/04/17 09:58, Ralf Reköndt wrote: Yes, would be interesting to know, how QLib does this with its compiled "resident" extensions. Ralf -Original-Nachricht- Betreff: Re: [Ql-Users] Marcel has done it again - SMSQE 3.31 Datum: 2017-04-11T10:47:36+0200 Von: "Jan Bredenbeek" On 11 April 2017 at 10:07, Derek Stewart wrote: Hi Marcel, Do you think it is possible for the SMSQ/E internal compiler produce a compiled version of the SBASIC programme? You can EXEC a SBASIC program in the same way as a 'normal' executable program on SMSQ/E (which actually starts another instance of SBASIC). But the code produced by the real-time compiler is not real 68000 code but pseudo-code and needs the SBASIC environment to work. So it cannot be a stand-alone EXECable program unless the SBASIC runtime environment also comes with it. Nevertheless it would be a great idea if you could write a procedure in SBASIC and LRESPR the compiled code as SBASIC extension so you have it always available. AFAIK there is no higher-level language compiler capable of producing SBASIC extensions - or perhaps Qliberator? Jan. Hi, Qliberator has a nice feature that S*Basic procedures and Functions can be compiled and loaded as Resident Procedures and Functions using the EXTERNAL for single Procedure or Function and EXT_ALL for all Procedures and Functions directives in REMark statements. Something like that would be nice to have built into SMSQ/E. ___ QL-Users Mailing List
Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
Il 11 apr 2017 10:47, "Jan Bredenbeek" ha scritto: On 11 April 2017 at 10:07, Derek Stewart wrote: Hi Marcel, > > Do you think it is possible for the SMSQ/E internal compiler produce a > compiled version of the SBASIC programme? You can EXEC a SBASIC program in the same way as a 'normal' executable program on SMSQ/E (which actually starts another instance of SBASIC). But the code produced by the real-time compiler is not real 68000 code but pseudo-code and needs the SBASIC environment to work. So it cannot be a stand-alone EXECable program unless the SBASIC runtime environment also comes with it. Nevertheless it would be a great idea if you could write a procedure in SBASIC and LRESPR the compiled code as SBASIC extension so you have it always available. AFAIK there is no higher-level language compiler capable of producing SBASIC extensions - or perhaps Qliberator? Jan. -- *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net ___ QL-Users Mailing List Yes you can build extension with qliberator ___ QL-Users Mailing List
Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
On 11/04/17 09:58, Ralf Reköndt wrote: Yes, would be interesting to know, how QLib does this with its compiled "resident" extensions. Ralf -Original-Nachricht- Betreff: Re: [Ql-Users] Marcel has done it again - SMSQE 3.31 Datum: 2017-04-11T10:47:36+0200 Von: "Jan Bredenbeek" On 11 April 2017 at 10:07, Derek Stewart wrote: Hi Marcel, Do you think it is possible for the SMSQ/E internal compiler produce a compiled version of the SBASIC programme? You can EXEC a SBASIC program in the same way as a 'normal' executable program on SMSQ/E (which actually starts another instance of SBASIC). But the code produced by the real-time compiler is not real 68000 code but pseudo-code and needs the SBASIC environment to work. So it cannot be a stand-alone EXECable program unless the SBASIC runtime environment also comes with it. Nevertheless it would be a great idea if you could write a procedure in SBASIC and LRESPR the compiled code as SBASIC extension so you have it always available. AFAIK there is no higher-level language compiler capable of producing SBASIC extensions - or perhaps Qliberator? Jan. Hi, Qliberator has a nice feature that S*Basic procedures and Functions can be compiled and loaded as Resident Procedures and Functions using the EXTERNAL for single Procedure or Function and EXT_ALL for all Procedures and Functions directives in REMark statements. Something like that would be nice to have built into SMSQ/E. -- Regards, Derek ___ QL-Users Mailing List
Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
Jan Bredenbeek wrote: > Nevertheless it would be a great idea if you could write a procedure in > SBASIC and LRESPR the compiled code as SBASIC extension so you have it > always available. AFAIK there is no higher-level language compiler capable > of producing SBASIC extensions - or perhaps Qliberator? This is possible with QLiberator. No idea how this works in detail, though. Cheers, Marcel ___ QL-Users Mailing List
Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
Derek Stewart wrote: > Do you think it is possible for the SMSQ/E internal compiler produce a > compiled version of the SBASIC programme? Perhaps it's possible, but I don't see a use case for it as there is already QLiberator and Turbo for that. And Turbo is probably faster. Marcel ___ QL-Users Mailing List
Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
Francois Lanciault wrote: > With all those discussions about bug correction and the good, > benevolent people who spend time to hunt them down, I wonder : > > Is there a proper way to report bugs in SMSQ/E ? > > Does asking kindly on this list enough ? :-) Yeah, that is probably your best bet. Bribes work, too, of course :-P Cheers, Marcel ___ QL-Users Mailing List
Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
Yes, would be interesting to know, how QLib does this with its compiled "resident" extensions. Ralf -Original-Nachricht- Betreff: Re: [Ql-Users] Marcel has done it again - SMSQE 3.31 Datum: 2017-04-11T10:47:36+0200 Von: "Jan Bredenbeek" On 11 April 2017 at 10:07, Derek Stewart wrote: Hi Marcel, > > Do you think it is possible for the SMSQ/E internal compiler produce a > compiled version of the SBASIC programme? You can EXEC a SBASIC program in the same way as a 'normal' executable program on SMSQ/E (which actually starts another instance of SBASIC). But the code produced by the real-time compiler is not real 68000 code but pseudo-code and needs the SBASIC environment to work. So it cannot be a stand-alone EXECable program unless the SBASIC runtime environment also comes with it. Nevertheless it would be a great idea if you could write a procedure in SBASIC and LRESPR the compiled code as SBASIC extension so you have it always available. AFAIK there is no higher-level language compiler capable of producing SBASIC extensions - or perhaps Qliberator? Jan. -- *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net ___ QL-Users Mailing List
Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
On 11 April 2017 at 10:07, Derek Stewart wrote: Hi Marcel, > > Do you think it is possible for the SMSQ/E internal compiler produce a > compiled version of the SBASIC programme? You can EXEC a SBASIC program in the same way as a 'normal' executable program on SMSQ/E (which actually starts another instance of SBASIC). But the code produced by the real-time compiler is not real 68000 code but pseudo-code and needs the SBASIC environment to work. So it cannot be a stand-alone EXECable program unless the SBASIC runtime environment also comes with it. Nevertheless it would be a great idea if you could write a procedure in SBASIC and LRESPR the compiled code as SBASIC extension so you have it always available. AFAIK there is no higher-level language compiler capable of producing SBASIC extensions - or perhaps Qliberator? Jan. -- *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net ___ QL-Users Mailing List
Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
On 10/04/17 20:15, Marcel Kilgus wrote: Ralf Reköndt wrote: As this seems to be very near at QLib, it makes me wonder, if TT has any long lost source code of QLib. IIRC the QLib compiler was written in Basic. I don't think there are many similarities besides the basic concept. Marcel ___ QL-Users Mailing List Hi Marcel, Do you think it is possible for the SMSQ/E internal compiler produce a compiled version of the SBASIC programme? -- Regards, Derek ___ QL-Users Mailing List
Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
With all those discussions about bug correction and the good, benevolent people who spend time to hunt them down, I wonder : Is there a proper way to report bugs in SMSQ/E ? Does asking kindly on this list enough ? :-) François ___ QL-Users Mailing List
Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
Ralf Reköndt wrote: > As this seems to be very near at QLib, it makes me wonder, if TT has any > long lost source code of QLib. IIRC the QLib compiler was written in Basic. I don't think there are many similarities besides the basic concept. Marcel ___ QL-Users Mailing List
Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
As this seems to be very near at QLib, it makes me wonder, if TT has any long lost source code of QLib. Marcel Kilgus: Jan Bredenbeek wrote: I've been doing a lot of disassembling on the original QL ROM but understanding the SuperBASIC parser was a bridge too far for me, so I found it a very interesting read. It raises one question though - is SBASIC an interpreter or a real-time compiler? It's a compiler that compiles to intermediate code and an interpreter for this code. Basically the same as a real-time QLiberator. And actually similar to how modern languages do this, like Java and C# (if we disregard the later hot-spot compilation step). I'm still working on BASICODE and hit upon another 'feature' which works differently in SBASIC: the vector at $138 can be used to LIST a number of lines (from D4 to D6), but in the original ROMs and Minerva it can also be used to execute a DLINE when called with D7<>0 (I believe the TK2 ED command makes extensive use of this). However in SBASIC the DLINE feature doesn't work, and from examining the code I could deduce that D7 isn't being tested at all! Haven't investigated anything in this regard, but full source code for TK ED is available and other than a different way to call the vectored routines it's identical between QDOS and SMSQ/E. ___ QL-Users Mailing List
Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
Jan Bredenbeek wrote: > I've been doing a lot of disassembling on the original QL ROM but > understanding the SuperBASIC parser was a bridge too far for me, so I found > it a very interesting read. It raises one question though - is SBASIC an > interpreter or a real-time compiler? It's a compiler that compiles to intermediate code and an interpreter for this code. Basically the same as a real-time QLiberator. And actually similar to how modern languages do this, like Java and C# (if we disregard the later hot-spot compilation step). > I'm still working on BASICODE and hit upon another 'feature' which works > differently in SBASIC: the vector at $138 can be used to LIST a number of > lines (from D4 to D6), but in the original ROMs and Minerva it can also be > used to execute a DLINE when called with D7<>0 (I believe the TK2 ED > command makes extensive use of this). However in SBASIC the DLINE feature > doesn't work, and from examining the code I could deduce that D7 isn't > being tested at all! Haven't investigated anything in this regard, but full source code for TK ED is available and other than a different way to call the vectored routines it's identical between QDOS and SMSQ/E. Cheers, Marcel ___ QL-Users Mailing List
Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
Op 8/04/2017 om 10:15 schreef Wolf: Hi all, Marcel has done it again - SMSQE 3.31 is out now. Marcel has fixed the LRESPR bug. LRESPRing sbasic extensions in a procedure no longer crashes the machine. David Westbury also contributed valuable code: RPIXL now also works in 8 and 16 bit modes. Finally, the string slicing behaviour fix was reverted. SMSQ/E will not complain anymore if you try to start a slice of a string 1 past its length. www.wlenerz.com/smsqe Have fun! Wolfgang ___ QL-Users Mailing List Hi, Many thanks to Marcel and David. François Van Emelen ___ QL-Users Mailing List
Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
Hi Marcel, On 10 April 2017 at 00:28, Marcel Kilgus wrote: > Wolf wrote: > > Marcel has done it again - SMSQE 3.31 is out now. > > > > Marcel has fixed the LRESPR bug. LRESPRing sbasic extensions in a > > procedure no longer crashes the machine. > > Thank you Wolfgang. I have actually written down part of the journey > in fixing this bug, so if this sort of technical thing interests you, > here it is: > > https://www.kilgus.net/2017/04/10/sbasic-bug-boogie/ > > It includes a rough description of how SBasic works internally, partly > so I can read it myself if I ever need it again. The rest I still > consider pure Voodoo ;-) > I've been doing a lot of disassembling on the original QL ROM but understanding the SuperBASIC parser was a bridge too far for me, so I found it a very interesting read. It raises one question though - is SBASIC an interpreter or a real-time compiler? I'm still working on BASICODE and hit upon another 'feature' which works differently in SBASIC: the vector at $138 can be used to LIST a number of lines (from D4 to D6), but in the original ROMs and Minerva it can also be used to execute a DLINE when called with D7<>0 (I believe the TK2 ED command makes extensive use of this). However in SBASIC the DLINE feature doesn't work, and from examining the code I could deduce that D7 isn't being tested at all! I discovered this when I testing my BCLOAD extension which should delete all lines from 1000 to the end and then read in a BASICODE program, translating it to S*BASIC on the fly so it heavily depends on the S*BASIC vectors. On JM/JS/Minerva it worked as expected but in SBASIC it actually merged the old and new programs! It looks like I have to write this code myself now (which is not too difficult as it's merely scanning the program for line 1000 and then set BV.PFP to the end of the line just before it). regards, Jan. -- *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net ___ QL-Users Mailing List
Re: [Ql-Users] Marcel has done it again - SMSQE 3.31
Wolf wrote: > Marcel has done it again - SMSQE 3.31 is out now. > > Marcel has fixed the LRESPR bug. LRESPRing sbasic extensions in a > procedure no longer crashes the machine. Thank you Wolfgang. I have actually written down part of the journey in fixing this bug, so if this sort of technical thing interests you, here it is: https://www.kilgus.net/2017/04/10/sbasic-bug-boogie/ It includes a rough description of how SBasic works internally, partly so I can read it myself if I ever need it again. The rest I still consider pure Voodoo ;-) All the best, Marcel ___ QL-Users Mailing List
[Ql-Users] Marcel has done it again - SMSQE 3.31
Hi all, Marcel has done it again - SMSQE 3.31 is out now. Marcel has fixed the LRESPR bug. LRESPRing sbasic extensions in a procedure no longer crashes the machine. David Westbury also contributed valuable code: RPIXL now also works in 8 and 16 bit modes. Finally, the string slicing behaviour fix was reverted. SMSQ/E will not complain anymore if you try to start a slice of a string 1 past its length. www.wlenerz.com/smsqe Have fun! Wolfgang ___ QL-Users Mailing List
