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.
