From owner-cvs-all Thu Dec 7 14:15: 4 2000 From owner-cvs-all@FreeBSD.ORG Thu Dec 7 14:15:00 2000 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id E41F737B400; Thu, 7 Dec 2000 14:14:59 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB7MEhF13510; Thu, 7 Dec 2000 14:14:43 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Dec 2000 14:14:43 -0800 (PST) From: Matt Dillon Message-Id: <200012072214.eB7MEhF13510@earth.backplane.com> To: "Daniel C. Sobral" Cc: John Baldwin , Jeroen Ruigrok van der Werven , cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/usr.bin/tail forward.c read.c reverse.c tail References: <3A2EEF7B.6F8F2BE@newsguy.com> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Not true. The register keyword is _not_ ignored and _does_ change :register allocation. I know. I spent some time looking at the assembler :code generated from regex, which makes extensive use of register :keyword. : :-- :Daniel C. Sobral (8-DCS) In general, there isn't much point in using 'register' any more. Old compilers only allocated registers when you told them to. Newer compilers (generally anything newer then 15-20 years ago) will automatically allocate registers and the 'register' keyword will just mess around with the selection heuristic to make it 'more likely'. Not to mention the fact that declaring registers in one architecture to optimize code can very well deoptimize it for another architecture. This goes all the way back to the 'writing hand assembly to optimize the code' verses 'let the compiler do it' argument. The 'let the compiler do it' argument eventually won, because porting assembly between architectures is rather difficult. While the register keyword isn't quite that bad, the portability argument still holds. I still remember all the 'register'ized hand-optimized C code and embedded assembly in games and libraries specifically optimized for VAXen. It's still very much in evidence... anyone remember all the garbage that used to be in the 'compress' program to make it go fast on a vax? I sure do! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message