>This makes good sense and is a resonable plan for the future. >The only problem with the conversion to C is that it may not >fit into an old machine.
Sure. I envisaged that any project in C would be only as a way forward for the higher spec. machines, existing and under development. The current SMSQ/E would need to be maintained for as long as necessary to support the older hardware and to allow old apps to still be run. A requirement of any newer OS versions would be to support the same filesystems, offer the same user interfaces, same system calls [where applicable] and run SBASIC programs unmodified, but beneath the skin would be totally different beasts. The actual mechanism for passing parameters to system calls would obviously vary for different platforms as they are 68k register based at present but the C libraries would take care of that. BTW I tried to look at the documentation on the SMSQ/E source CD. A few of them are Word 6.0 which I could open in Wordpad, but most are Word 2.0 which I could not. I will have to bring the CD to work next week to read them, that is if Word 97 or 2000 can open them. Ian. >-----Original Message----- >From: John Sadler [mailto:[EMAIL PROTECTED]] >Sent: 11 July 2002 11:40 >To: [EMAIL PROTECTED] >Subject: Re: [ql-users] SMSQ Source upgrading, & assembling. > > > >This makes good sense and is a resonable plan for the future. >The only problem with the conversion to C is that it may not >fit into an old >machine. > >----- Original Message ----- >From: <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Wednesday, July 10, 2002 12:42 PM >Subject: RE: [ql-users] SMSQ Source upgrading, & assembling. > > > >>Let's try to be reasonable here. Up until now, development of the >>sources - ALL OF THEM - was done with the system as described >>in the style guide. In my mind, it is essential that, at least for the >>time being, we keep that system: if we change tools and sources >>at the same time, the complexity will just go up. > >I agree with that, for the time being. The code has only just >been made >available. It would be best if a few people started looking >at it, figuring >out how to do a build in the most painless way - i.e. using >the same tools >TT used - and put some documentation together, before everyone dives in >trying to solve the same problems with a lot of wasted effort. > Let's learn >to walk before we run. > >But for the future... >There is a wide variety of platforms to be supported by 'one coherent >version'. It is good that the whole range of QL-like systems >can run QL >applications when the users want/need to use them, but it >seems a shame that >the fastest machines should only be supported by lowest common >denominator >code if strict backwards compatibility is not always required. >The Q60 needs a fully optimized SMSQ/E, freely using whatever 68060 >instructions and techniques that will extract best performance >from that >platform. Is the QL community really so small that a few >branches of SMSQ/E >could not be supported while maintaining sufficient central control to >prevent them mutating into unrecognizable monsters? The >coherence could be >maintained as a standard for system calls, parameters, responses ... >"Qosix"? ;o) with a suite of test programs to demonstrate >compliance by new >versions. The trouble with hardware that becomes obsolete is that it >depends on manufacturers with suitable plant to maintain >production as sales >dwindle; the chips are just too complex for a bunch of enthusiastic >hobbyists to make in their sheds (unless they have extremely >well equipped >sheds!). Software on the other hand, is intellectual >property. It can be >kept alive indefinitely by jumping and adapting to new hosts. QPC has >already enabled that by the emulation route. If you tie software to >hardware it will die when the hardware does, which it will eventually. >Linux has been able to make the jump from x86 to 68k architecture and >running successfully on Q40 and Q60, so SMSQ/E should be able >to make the >jump in the opposite direction. But first, it would be >necessary to prise it >away from its assembler dependence (much as I hate to say it - I always >liked assembler). I once worked for a firm that produced a proprietary >operating system that was written in assembler. It was a good >system (well, >I liked it) but when the new wave of microprocessor-based >boxes with the new >32 bit MPUs from Motorola and later Intel started to target >the minicomputer >market, rather than try to port their OS to these machines, >they moved to >Unix because it was already C and more easily ported (plus it was the >beginning of the era of open systems and they realized that >proprietary was >no longer the place to be if you wanted to survive). > >After the current SMSQ source has been digested I really think >there should >be a project to get all the non-machine dependent parts rewritten in C. >Apart from the portability, it would also become easier to develop new >features. It would be nice if Tony Tebby gave his blessing to >it, so that >it could become an official version (if it ever even got off >the ground). > >Ian. > > > > > Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
