Path: utzoo!utgpu!bnr-vpa!bnr-fos!bnr-public!schow From: schow@bnr-public.uucp (Stanley Chow) Newsgroups: comp.arch Subject: Re: Complex Instructions Message-ID: <483@bnr-fos.UUCP> Date: 8 May 89 04:10:32 GMT References: <426@bnr-fos.UUCP> <504@daitc.daitc.mil> Sender: news@bnr-fos.UUCP Reply-To: schow%BNR.CA.bitnet@relay.cs.net (Stanley Chow) Organization: Bell-Northern Research, Ottawa, Canada Lines: 49 Summary: Followup-To: Keywords: In article <504@daitc.daitc.mil> jkrueger@daitc.daitc.mil (Jonathan Krueger) writes: >In article <426@bnr-fos.UUCP>, schow@bnr-public (Stanley Chow) writes: >>it is not necessary for all programmers to know enough to use >>the specail instructions. Some guru can set it up and everyone can >>then use the pre-built modules. Depending on how you set everything >>up, the compiler does not have to be smart at all. > >Of course, but you lose the performance advantage if the modules get >called frequently and require significant setup (e.g. can't maintain >state for multiple callers or sequences) with respect to work >performed. Or to put it another way, That Way Lies Threaded Code. >However, this isn't an argument for Better Living Through Inlining, >rather an appeal for analysis and measurement of the tradeoffs. > This depends a lot on the system and language you use. We spend considerable time to make sure the utilities are suited to the application. (This is easy, since this whole system is a single application, and we have measured it to death). In our operating system, maintaining states for multiple callers is easy and essentially free. Most of the funny opcodes can be easily generated by a peepholer and the really strange opcodes are what we call Intrinsics - half way between macros and inlining. >>For example, we have a system with really wild instructions that gets >>generated even though the user don't know what they are and the >>compiler does only peephole optimization. As is turns out, having >>atomic operations for free is really nice. > >Sounds like you've managed to let your users express what they want in >terms familiar to them but also understandable to the language >translator, following which optimization to particular hardware can be >done in a reasonable way. By any chance, would this be done by way of >a function library? We use just about every trick in the book and some that aren't. Since we have a project that is big enough to support our own language and operating system, we have a lot of freedom. Usually, we figure out the hardware/firmware limits, decide how we want it in the language, then change the language/compiler and operating system to suit. Sorry I can't give details. Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow (613) 763-2831 ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public I am just a small cog in a big machine. I don't represent nobody.