>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. >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >Sent: 10 July 2002 07:01 >To: [EMAIL PROTECTED] >Subject: Re: [ql-users] SMSQ Source upgrading, & assembling. > > > >On 8 Jul 2002, at 23:55, John Sadler wrote: > >> >> Are we in danger of restricting SMSQE to be assembled with Qmac >> restricting ourselves to 68000 code, casting aside all those >QLers who >> have invested in a Super Gold Card, QXL, Q40 or Q60? > >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. > >> You are not going >> to be able to do some serious number crunching if you are not >>going to use the floating point extensions. >> You are not going to stop the QL >> crashing without using the memory management unit of the 68030+ chips >> and instruction set. > >Oh, come on, that's just not true, and you (should) know it. To take >a (bad) example, Windows uses the mem prot, and still manages >to crash irretrievably, and i can be trashed by an application. > >I do agree that using memory protection would be a good idea. >Howevern before you do even think about implementing it, have a >good look at the source code, and see all of the problems that go >with it. Draw a road map of all of the changes that will have to be >made etc... > >> Gwass is the only assembler which can cope with >> 68020+ and floating point instructions. > >Correct. >However, please remember one thing: SMSQ/E also runs on >machines that don't have a 68020+ (Gold card, Ataris, QPC come >to mind). >I have sufficiently stated here that I want coherent versions... >which doesn(t mean that, e.g. the Q60, shouldn't be able to use >native facilities. > >> Furthermore Gwass is >> maintained and can be extended and corrected as required, >whereas Qmac >> is not and you are going to have to put up with its errors and >> restrictions. George has offered to convert the macros. What better >> offer could you have? > >Change GWASS ? > >> If you are not going to use these features there does not seem much >> point in upgrading SMSQE. Just treat the QL like a crystal radio. >> Something to nostalgically recall the pioneering days of >computing, or >> leave to the local museum to be looked at by our grandchildren. > >Facetiousness put aside, I'm pretty sure that we'll be able to find a >modus vivendi that will allow us to move forward. If things really >needing a 68020+ instruction set really come out, there is always a >possibility of making it into modules. Even if I wanted to be really >strict about the QMAC compatibility, ways could be found (off the >top of my head, use DC.W instructions, for example). > >Wolfgang > 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.
