Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: John Savard Newsgroups: comp.arch Subject: Re: "Mini" tags to reduce the number of op codes Date: Thu, 04 Apr 2024 21:13:13 -0600 Organization: A noiseless patient Spider Lines: 24 Message-ID: <6mqu0j1jf5uabmm6r2cb2tqn6ng90mruvd@4ax.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Date: Fri, 05 Apr 2024 03:13:15 +0200 (CEST) Injection-Info: dont-email.me; posting-host="3c07d85c4e653c1adc6fe68b70f91598"; logging-data="1213503"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX185X2WdxTRFtvSjWXewtWVytmKLEUAM54s=" Cancel-Lock: sha1:tPUIG3W7XZPfo7ef355kMJl1LLc= X-Newsreader: Forte Free Agent 3.3/32.846 Bytes: 2133 On some older CPUs, there might be one set of integer opcodes and one set of floating-point opcodes, with a status register containing the integer precision, and the floating-point precision, currently in use. The idea was that this would be efficient because most programs only use one size of each type of number, so the number of opcodes would be the most appropriate, and that status register wouldn't need to be reloaded too often. It's considered dangerous, though, to have a mechanism for changing what instructions mean, since this could let malware alter what programs do in a useful and sneaky fashion. Memory bandwidth is no longer a crippling constraint the way it was back in the days of core memory and discrete transistors - at least not for program code, even if memory bandwidth for _data_ often limits the processing speed of computers. This is basically because any program that does any real work, taking any real length of time to do its job, is going to mostly consist of loops that fit in cache. So letting program code be verbose if there are other benefits obtained thereby is the current conventional wisdom. John Savard