Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!ukc!inmos!mph From: mph@lion.inmos.co.uk (Mike Harrison) Newsgroups: comp.lang.misc Subject: Algol 68. Message-ID: <3968@ganymede.inmos.co.uk> Date: 7 Feb 90 10:55:05 GMT References: <4561@scolex.sco.COM> <14214@lambda.UUCP> <2217@sunset.MATH.UCLA.EDU> <4466@brazos.Rice.edu> Sender: news@inmos.co.uk Reply-To: mph@inmos.co.uk (Mike Harrison) Organization: INMOS Limited, Bristol, UK. Lines: 52 In article pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes: >Algol68 is difficult to *parse*, but it has been carefully >designed to make efficient code possible, and indeed even easy. >Array slicing, for example, is there for this reason, as are >other things. Too bad that something like 'fast' is missing (but >'ronly' is there). I have just looked at my copy of the 'revised report' and can't find any reference to 'ronly', [I didn't think I had come across it], so what is it? Some kind of pragmat (and in what implementation) ? While talking of pragmats, in S3, ICL's Algol68 based systems langauge, there was a 'pr' RARELY, which informed the compiler that the relevant code would be obeyed only on 'rare' occasions. This could be used for the code of error condition branches of 'if' clauses. The effect was that the code was generated in a different code area, and could be loaded into a different segment, thus improving code locality. >On this let me disagree too. The hints should not get thrown out; >they are valuable, *quality* information. The compiler writer >should not believe that it can (reliably!) second guess the >author as to the semantic/pragmatic properties of the program. > >The author should describe them as clearly as possible, and the >compiler should treasure such information. Of course the author >should be spared (not always! if it is *really* important, >machine dependent considerations should enter into the design of >a program) the work of machine dependent optimization (which is >actually just competent code generation), because there the >compiler is in charge. > Here I agree, a sensible set of pragmas, can do much to improve the quality of generated code, by hinting to the compiler that some complex check is worth performing. For example, in Ada there is an optimisation for passive tasks, which eliminates much of the full generality of tasks [Nassi & Haberman, I think]. Searching for such cases is hard and time consuming, but if a user could suggest such an optimisation in respect of a particular task eg. by: pragma MONITOR_TASK(mytask); it is fairly easy to check the validity. Mike, Michael P. Harrison - Software Group - Inmos Ltd. UK. ----------------------------------------------------------- UK : mph@inmos.co.uk with STANDARD_DISCLAIMERS; US : mph@inmos.com use STANDARD_DISCLAIMERS;