Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!news.glorb.com!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail From: torbenm@diku.dk (Torben Ægidius Mogensen) Newsgroups: comp.arch Subject: Re: Joint Design of Instruction Set and Language References: <4e1f887a.16587593@news.aioe.org> <2011Jul15.101407@mips.complang.tuwien.ac.at> Date: Fri, 15 Jul 2011 14:26:33 +0200 Message-ID: <7ztyanlog6.fsf@ask.diku.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:Vys6xOdIyp6Z4eiafIaDHLgJDQ0= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 28 Organization: SunSITE.dk - Supporting Open source NNTP-Posting-Host: 130.225.96.225 X-Trace: news.sunsite.dk DXC=1R`KgI?;8JDe:i55N5G3eEYSB=nbEKnkK]YNBAY4>>TIeA0c^o`FO0DNW[cF@L;gDGF5\^6VX=jYD6J_7@hj^5RG:6^ In some sense many RISCs are C processors (or maybe Pascal), because > the benchmarks they were tuned for were written in C or Pascal, Benchmarks are still largely written in C, so you could say that nearly all modern processors are, if not designed for C, at least tuned for maximum C performance. Even media ISA extensions, though mostly programmed in assembler, are mainly intended for writing libraries that make C benchmarks (such as media decoders) run faster. More importantly, design decision that may potentially hurt C performance are never made, even if they might benefit implementations of other languages. And features that are difficult to use from C but may benefit other languages have low priority. For example, few processors designed after 1990 have good support for multiprecision integer arithmetic (such as carry flags, NxN->2N multipliers and integer divison instructions that also provide remainder). Similarly, the vendor-mandated procedure call standards are also highly C specific: No standardised way of handling exceptions, multiple function results, tail calls, GC etc., as these are not interesting for C. Torben