Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site sjuvax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!sjuvax!bbanerje From: bbanerje@sjuvax.UUCP (B. Banerjee) Newsgroups: net.lang.c Subject: Potential optimisation? Message-ID: <763@sjuvax.UUCP> Date: Sat, 19-Jan-85 01:21:37 EST Article-I.D.: sjuvax.763 Posted: Sat Jan 19 01:21:37 1985 Date-Received: Sun, 20-Jan-85 08:01:33 EST Distribution: net Organization: Saint Josephs Univ. Phila., Pa. Lines: 76 Hi, Please don't flame me, despite what my .signature entry may say. This is in the spirit of honest enquiry. I don't know whether the following is feasible in the presence of signals and the like. I was thinking of the possible ways that C could be sped up, in a general fashion. Part of the philosophy of using procedural languages such as C, is that the incentive is present to break up the program into small manageable functions. Much of this incentive is lost if the function call is overly expensive. 1) The current process of passing parameters on the stack has many advantages. Primary among these are the capabilities of declaring routines that take a variable number of arguments (*Yes*, they are often necessary, and even clean). Also, a consistent calling interface is desirable when linking in separately compiled, or assembly language routines. Unfortunately, this adds a great deal of unnecessary overhead. One way to handle this would be to handle calls to 'static' functions differently, based on observed usage in the rest of the file (NOTE: this probably would require multiple passes). Parameterless static functions could be called via a 'jsr' or equivalent. Functions with fewer than 'n' constant arguments could have their arguments passed in registers. Static functions whose usage indicated a VARARGS usage would have the parameters passed in the usual fashion. Static functions which are only referenced once or twice could be expanded inline. Now, so far there is nothing new here. However.... I took a look at a lot of C code on my (4.2 BSD) system. An informal guess would be that over 50% of the functions in the source files could be declared as 'static'. Now, let us say that we have another keyword 'exported' which is used to label those functions which are called from other source files. All functions which were *not* declared to be *exported* would be considered static by default. This would allow the efficient generation of code. It would also be easier to read code that used this, as one would not have to sit down with a cross reference listing. Furthermore, register allocation could be done on an inter-functional basis. Lastly, the code could be portable through the use of ... # define exported /* foobar */ in a header file, effectively stripping them in the case where they were not understood. 2) In a UNIX C compiler (to the best of my knowledge) two assembly procedures CSV and CRET are used to save and restore the registers in the *called* procedure. I fail to see why this is desirable. The *calling* procedure has full knowledge of which registers are being used and can save them itself. This may not result in savings, but I don't see where it can result in a performance degradation. 3) Automatic data definitions are always allocated space on the stack. This is fine in the presence of recursive functions. However, in practice, recursive functions are not very heavily used. Some means of data flow analysis might allow the allocation of automatic data statically at compile time, with each datum at a constant offset from the start of the object file. The data flow analysis could enable the re-use of space. This would allow processes to take up less space while running, as the maximum stack size would be known at compile time. Of course, recursive functions would still have their local data allocated on the stack. Well, what do you think. I would appreciate some feedback on this. Please reply by mail. If the responses warrant it, I will summarize to this group. Regards, -- Binayak Banerjee {allegra | astrovax | bpa | burdvax}!sjuvax!bbanerje P.S. Send Flames, I love mail.