Re: Increasing minimum 'i386' processor
Ian Jackson ijack...@chiark.greenend.org.uk writes: The 486-class processors that would no longer be supported are: 1. All x86 processors with names including '486' I'm still running the machine below, and it would be irritating to have to replace it. ... vendor_id : CentaurHauls cpu family: 6 model : 7 model name: VIA Samuel 2 AFAICT, the above would be considered a 586-class CPU... so no prob! -Miles -- A zen-buddhist walked into a pizza shop and said, Make me one with everything. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buor50e1eo5@dhlpc061.dev.necel.com
Re: 486 still being sold NEW / was Re: Increasing minimum 'i386' processor
On Wednesday 07 Dec 2011, Toni Mueller wrote: On 11/21/2011 07:52 PM, Ben Hutchings wrote: Since we're theorising, rather than talking about actual users, my theory is that these are sold as replacements for installed systems, which will run the exact same software as the original - not Debian 7.0. It would be silly to start a new deployment reliant on parts that have already been EOL'd. I may be mistaken, but the CPUs listed there are not original Intel, but some clones that still could or could not be in production. Seeing that these 486-class devices specify DDR2 as their memory interface suggests that they are really not that old. The Vortex DX chips are still being produced, and new boards produces that use them. They are generally new embedded boards. David -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201112070943.46877.david.goodeno...@btconnect.com
Re: 486 still being sold NEW / was Re: Increasing minimum 'i386' processor
On Wed, 2011-12-07 at 09:43 +, David Goodenough wrote: On Wednesday 07 Dec 2011, Toni Mueller wrote: On 11/21/2011 07:52 PM, Ben Hutchings wrote: Since we're theorising, rather than talking about actual users, my theory is that these are sold as replacements for installed systems, which will run the exact same software as the original - not Debian 7.0. It would be silly to start a new deployment reliant on parts that have already been EOL'd. I may be mistaken, but the CPUs listed there are not original Intel, but some clones that still could or could not be in production. Seeing that these 486-class devices specify DDR2 as their memory interface suggests that they are really not that old. The Vortex DX chips are still being produced, and new boards produces that use them. They are generally new embedded boards. I love how people are still following up with information I already found and posted. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Re: 486 still being sold NEW / was Re: Increasing minimum 'i386' processor
On 11/21/2011 07:52 PM, Ben Hutchings wrote: Since we're theorising, rather than talking about actual users, my theory is that these are sold as replacements for installed systems, which will run the exact same software as the original - not Debian 7.0. It would be silly to start a new deployment reliant on parts that have already been EOL'd. I may be mistaken, but the CPUs listed there are not original Intel, but some clones that still could or could not be in production. Seeing that these 486-class devices specify DDR2 as their memory interface suggests that they are really not that old. -- Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4edeac94.3090...@debian.org
Re: Increasing minimum 'i386' processor
Hello, 2011/11/23 Matthias Klose d...@debian.org: On 11/19/2011 11:42 PM, Ben Hutchings wrote: (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) This would allow the use of optimisations and new instructions throughout userland that improve performance for the vast majority of users. could you give numbers what kind of improvements you would expect? The biggest burden for i386 is the register pressure, which you won't fix with targeting a newer processor. The better approach would be a new port, the x32 architecture; I don't know if anybody did look into building a distribution for this architecture yet. The next thing could be to default to sse2 math instead of x87 (didn't look if this is already the default for x32). FWIW, Yocto has attempted to build an image for x32: https://wiki.yoctoproject.org/wiki/X32_abi Yes, x32 defaults to SSE and improvements expected 7-10% on integer math over ia32 (5-8% over intel64) and 5-11% on fp math over ia32. Figures from http://linuxplumbersconf.org/2011/ocw/system/presentations/531/original/x32-LPC-2011-0906.pptx Cheers, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caodfwegyeux2ybij1i5orxfs2fme5mrw-eoesv2l_s2y2jh...@mail.gmail.com
Re: Increasing minimum 'i386' processor
On Sun, Nov 20, 2011 at 08:48:08PM +, Ben Hutchings wrote: /usr/lib/i386-linux-gnu/i486/libcrypto.so.1.0.0: cpuid /usr/lib/i386-linux-gnu/i486/libcrypto.so.1.0.0: rdtsc I should probably drop that i486 variant anyway, since i486 is already the default. I should also consider dropping the i586 variant. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2024231832.ga15...@roeckx.be
Re: Increasing minimum 'i386' processor
Matthias Klose d...@debian.org writes: On 11/19/2011 11:42 PM, Ben Hutchings wrote: The i386 architecture was the first in Linux and in Debian, but we have long since dropped support for the original i386-compatible processors and now require a minimum of a 486-class processor. I think it is time to increase the minimum requirement to 586-class, if not for wheezy then immediately after. note that squeeze is built this way, and single packages like openjdk only build for 586. (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) This would allow the use of optimisations and new instructions throughout userland that improve performance for the vast majority of users. could you give numbers what kind of improvements you would expect? The biggest burden for i386 is the register pressure, which you won't fix with targeting a newer processor. The better approach would be a new port, the x32 architecture; I don't know if anybody did look into building a distribution for this architecture yet. The next thing could be to default to sse2 math instead of x87 (didn't look if this is already the default for x32). Matthias Where the relevant patches added to binutils and gcc for this? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obw3w2uc.fsf@frosties.localnet
Re: Increasing minimum 'i386' processor
[Goswin von Brederlow] Where the relevant patches added to binutils and gcc for this? See for yourself: http://sites.google.com/site/x32abi/ -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2023122412.gf2...@p12n.org
Re: Increasing minimum 'i386' processor
On Wed, 2011-11-23 at 00:44 +0100, Matthias Klose wrote: On 11/19/2011 11:42 PM, Ben Hutchings wrote: The i386 architecture was the first in Linux and in Debian, but we have long since dropped support for the original i386-compatible processors and now require a minimum of a 486-class processor. I think it is time to increase the minimum requirement to 586-class, if not for wheezy then immediately after. note that squeeze is built this way, and single packages like openjdk only build for 586. So I was told. I must have missed the discussion of this prior to the change. Somehow it seems to be missing from the release notes too. (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) This would allow the use of optimisations and new instructions throughout userland that improve performance for the vast majority of users. could you give numbers what kind of improvements you would expect? [...] That I don't know. Ben. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else. signature.asc Description: This is a digitally signed message part
Re: Increasing minimum 'i386' processor
On Wed, Nov 23, 2011 at 07:20:11PM +, Ben Hutchings wrote: The i386 architecture was the first in Linux and in Debian, but we have long since dropped support for the original i386-compatible processors and now require a minimum of a 486-class processor. I think it is time to increase the minimum requirement to 586-class, if not for wheezy then immediately after. (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) This would allow the use of optimisations and new instructions throughout userland that improve performance for the vast majority of users. I think this lacks perspective. It is far too late to try to improve i386 performance. Popularity-contest shows that i386 will not be the dominant architecture before the time Wheezy is released. So we can expect that in Wheezy time, i386 will be mostly a legacy platform used by older hardware and the vast majority of i386 users will be people stuck with an older computer, more interested by the continued support for their platform than by performance. Users seeking performance will use amd64, which offer more registers and and a larger address space. If we want to make a difference with performance, we should target the latest amd64 hardware, not i386. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2023223142.GC23122@yellowpig
Re: Increasing minimum 'i386' processor
On Tue, Nov 22, 2011 at 06:41:47AM +0100, Stephen Kitt wrote: On Sun, 20 Nov 2011 23:31:43 +, Ben Hutchings b...@decadent.org.uk wrote: 1. Find all ELF executable/library files. 2. Either: a. Work out which instructions should be excluded, depending on the directory. b. Skip files in hwcap directories and exclude all instructions missing from the minimum processor. 3. 'objdump -d | grep' with appropriate instruction regexp; fail if there's a match. http://dev.gentoo.org/~dirtyepic/bin/analyze-x86 is very handy for this, although it's quite CPU-intensive. OMGWTFBBQ... real5m26.459s user5m25.780s sys 0m0.108s How does one write Perl code that slow? This just has to be intentional -- they used an elaborate construct when a single hash lookup per line of disassembly is the obvious way. A quick and dirty change reduces execution time to 5.981s (5.975s of that is objdump -d). I also fail to see how the vendor of CPU you happen to be running the script on would matter -- there might be multiple minimal outputs but since the trade name (Pentium 4 as opposed to sse2) is meant for humans only anyway, there's no reason to be misleading. Not releasing a fixed version (too ugly to live), but if someone wants it, please say so, I can polish it for public consumption. -- 1KB // Yo momma uses IPv4! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2022112458.ga20...@angband.pl
Re: Increasing minimum 'i386' processor
* Ben Hutchings b...@decadent.org.uk, 2011-11-20, 20:48: Use of CPUID is probably safe in practice since most 486 models do implement it, though userland should really read /proc/cpuinfo. The other uses may be conditional on a CPU feature test but may well be bugs. Is format of /proc/cpuinfo documented anywhere? Does /proc/cpuinfo with the exist on non-Linux architectures? If yes, do they use the same format? Are the any ready-made libraries that can parse this file? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2022154721.ga3...@jwilk.net
Re: Increasing minimum 'i386' processor
Ben Hutchings writes (Increasing minimum 'i386' processor): The 486-class processors that would no longer be supported are: 1. All x86 processors with names including '486' I'm still running the machine below, and it would be irritating to have to replace it. Perhaps a better approach would be to suggest that people with shiny new hardware should be running amd64 kernels with i386 userland, or even amd64 (with multiarch i386 for proprietary crap that isn't available for amd64) ? Ian. processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 7 model name : VIA Samuel 2 stepping: 3 cpu MHz : 533.401 cache size : 64 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow bogomips: 1066.80 clflush size: 32 cache_alignment : 32 address sizes : 32 bits physical, 32 bits virtual power management: -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20171.53784.119523.574...@chiark.greenend.org.uk
Re: Increasing minimum 'i386' processor
On Tue, Nov 22, 2011 at 04:47:20PM +, Ian Jackson wrote: Ben Hutchings writes (Increasing minimum 'i386' processor): The 486-class processors that would no longer be supported are: 1. All x86 processors with names including '486' I'm still running the machine below, and it would be irritating to have to replace it. vendor_id : CentaurHauls model name: VIA Samuel 2 I don't see any 486 in this name. Bastian -- There's a way out of any cage. -- Captain Christopher Pike, The Menagerie (The Cage), stardate unknown. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2022172828.ga31...@wavehammer.waldi.eu.org
Re: Increasing minimum 'i386' processor
OoO Lors de la soirée naissante du mardi 22 novembre 2011, vers 18:28, Bastian Blank wa...@debian.org disait : The 486-class processors that would no longer be supported are: 1. All x86 processors with names including '486' I'm still running the machine below, and it would be irritating to have to replace it. vendor_id: CentaurHauls model name : VIA Samuel 2 I don't see any 486 in this name. This processor does not run with a 686 kernel and needs a 486 kernel. If I remember correctly, it is because the lack of CMOV instruction. Therefore, no problem with 586. -- Vincent Bernat ☯ http://vincent.bernat.im Indent to show the logical structure of a program. - The Elements of Programming Style (Kernighan Plauger) pgpVbq7hxHmAb.pgp Description: PGP signature
Re: Increasing minimum 'i386' processor
On Tue, Nov 22, 2011 at 04:47:20PM +, Ian Jackson wrote: Ben Hutchings writes (Increasing minimum 'i386' processor): The 486-class processors that would no longer be supported are: 1. All x86 processors with names including '486' I'm still running the machine below, and it would be irritating to have to replace it. As Bastian says, this does not look like a 486. The flags include tsc msr cx8. Perhaps a better approach would be to suggest that people with shiny new hardware should be running amd64 kernels with i386 userland, or even amd64 (with multiarch i386 for proprietary crap that isn't available for amd64) ? [...] I believe Debian should now treat amd64 as the default architecture for PCs. The i386 installer does provide it as an option in expert mode (though it's not on CD 1) but I'm not sure we're quite at the point where it should be automatically selected. In any case this is irrelevant to the question of optimising userland. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2022183646.gr3...@decadent.org.uk
Re: Increasing minimum 'i386' processor
CMOV, quick comment. Many apps don't reliably optimize -O3. CMOV saves 1 clock + 1 dword. There far lower branches to pick for debian to grow on (unless it's like req. to drive androids or real important). (note CMOV is not Ben's agenda as far as I have read. I say nothing there but good luck) CMOV + IDEA: ignore /proc? Do u debug trap invalid instr. reliably at which run-level? Use /proc or ask torvalds is safe :) Isn't there already debian utils up that ally? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ecbf168.7080...@cox.net
Re: Increasing minimum 'i386' processor
John D. Hendrickson and Sara Darnell, le Tue 22 Nov 2011 14:00:56 -0500, a écrit : CMOV saves 1 clock + 1 dword. Errr, and branch misprediction? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2022201903.GF4113@type
Re: Increasing minimum 'i386' processor
Josselin Mouette is apparently easily amused. He harasses me every time I use debian-devel mailing list, apparently automaticall (which is illegal in my country - though for now it's ok). Josselin Mouette wrote: Or in legacy; I've read about wishes of their own patent problems, capice? But ads a login can get out and having to be opensuse deeply compatible yet high unix efficient, Switching to all the road? Grub and having to maintain and inodes would be my slice single project need change if MIS USED by I already prepared considering hardware and drive in his response; mail, btw i've read most filesystem blocking code for demanding offered proof that i've read about the right arch; the tomb of each of my guess. It's a good day all the origional bug is i'm almost unsure why is good new work because they insert many And drive installed correctly after I move hack a isn't a ramdisk for the linux; allows a new work because they now have Fun! Michael Biebl v. If there's you sure if linux users anything they're hoping you'll make new problems they mount boot and privatizes gov. Are you rolling debian on people's comments! And mixed partitions is invalidated maybe you want highly specialized caching write code. Tftp boot disk and large disks, many drive large WD hardisks both have advice? That's Funny! Thus I might say and complicated bsd my guess; I thinking of their own patent problems, ide And disperses what are Have Fun! Debian new bugsy, non obstructing, no spin maybe you try want highly specialized caching write code for demanding Tmpfs to allow processes to hear about wishes of the right arch; eat the partition tables headers And considering hardware and what are you are? But with thought using I hope and large WD hardisks both Have fun! John I might say and ignores justice in his response; mail, btw i've read most filesystem Blocking caching code to kill any single user logins that i've read about wishes of delay of copying todos and not true, called? They prosecute you are you rolling debian bugs, I still don't share memory share memory why you should just dd, I And privatizes gov. Where's the people who are not always new software do it the drives with the need special exception in lk series any EZ drive data and tfpt is for special exception in lk they are you i might say and risk data one will it. Have fun! Whether is or way. I was provided it processes to get their own patent problems, capice? Why is blocking code to hack a backup directory is disagreeing with Just ignore them. Josselin Mouette wrote: I have a request for special exception in Wikipedia! Simple well knowns, non obstructing, no spin maybe not construed to hear about wishes of delay of! Is safe promised permanent IPs. I'm not survivable a bug is it hard be my Christmas John i already. It ignore mere talk about wishes of bsd about the support of any single project need to fix see like to me these problems capice? They promised permanent IPs. Or is of any EZ drive installed changing and tfpt is a major maintenance will care which is supporting optional no one block by checking for and booting. I have a request for special exception in Wikipedia! Simple well knowns, non obstructing, no spin maybe not construed to hear about wishes of delay of! Is safe promised permanent IPs. I'm not survivable a bug is it hard be my Christmas John i already. It ignore mere talk about wishes of bsd about the support of any single project need to fix see like to me these problems capice? They promised permanent IPs. Or is of any EZ drive installed changing and tfpt is a major maintenance will care which is supporting optional no one block by checking for and booting. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ecc11c7.6080...@cox.net
Re: Increasing minimum 'i386' processor
John D. Hendrickson and Sara Darnell, le Tue 22 Nov 2011 16:19:03 -0500, a écrit : Josselin Mouette is apparently easily amused. He harasses me every time I use debian-devel mailing list, apparently automaticall (which is illegal in my country - though for now it's ok). Josselin Mouette wrote: Or in legacy; I've read about wishes of their own patent problems, capice? But ads a login can get out and having to be opensuse deeply compatible yet high unix efficient, Switching to all the road? Grub and having to maintain and inodes would be my slice single project need change if MIS USED by I already prepared considering hardware and drive in his response; mail, btw i've read most filesystem blocking code for demanding offered proof that i've read about the right arch; the tomb of each of my guess. This looks random stuff to me. Not something that Josselin would write. I'd rather bet on a spammer using random From:. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2022212438.GG4113@type
Re: Increasing minimum 'i386' processor
On Tue, Nov 22, 2011 at 04:47:21PM +0100, Jakub Wilk wrote:
* Ben Hutchings b...@decadent.org.uk, 2011-11-20, 20:48:
Use of CPUID is probably safe in practice since most 486 models do
implement it, though userland should really read /proc/cpuinfo.
The other uses may be conditional on a CPU feature test but may
well be bugs.
Is format of /proc/cpuinfo documented anywhere?
Sadly, it is not documented explicitly.
Does /proc/cpuinfo with the exist on non-Linux architectures? If
yes, do they use the same format?
It is Linux-specific, but included in FreeBSD's Linux compatibility module.
I don't know whether Debian kFreeBSD loads that by default.
Are the any ready-made libraries that can parse this file?
Not that I know of.
However, if you're looking for specific x86 feature flags (which is
almost certainly what you need) you can use:
bool x86_has_feature(const char *name)
{
FILE *cpuinfo;
char *line = NULL, *p;
size_t line_len = 0, name_len = strlen(name);
bool found = false;
cpuinfo = fopen(/proc/cpuinfo, r);
if (!cpuinfo)
return false;
while (getline(line, line_len, cpuinfo) = 0 !found) {
if (strncmp(line, flags\t, 6))
continue;
p = line;
while ((p = strchr(p, ' ')) != NULL) {
p++;
if (strncmp(p, name, name_len) == 0
isspace((unsigned char)p[name_len])) {
found = true;
break;
}
}
}
fclose(cpuinfo);
return found;
}
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2022213747.gs3...@decadent.org.uk
Re: Increasing minimum 'i386' processor
On Tue, Nov 22, 2011 at 10:24:38PM +0100, Samuel Thibault wrote: John D. Hendrickson and Sara Darnell, le Tue 22 Nov 2011 16:19:03 -0500, a écrit : Josselin Mouette is apparently easily amused. He harasses me every time I use debian-devel mailing list, apparently automaticall (which is illegal in my country - though for now it's ok). Josselin Mouette wrote: Or in legacy; I've read about wishes of their own patent problems, capice? But ads a login can get out and having to be opensuse deeply compatible yet high unix efficient, Switching to all the road? Grub and having to maintain and inodes would be my slice single project need change if MIS USED by I already prepared considering hardware and drive in his response; mail, btw i've read most filesystem blocking code for demanding offered proof that i've read about the right arch; the tomb of each of my guess. This looks random stuff to me. Not something that Josselin would write. I'd rather bet on a spammer using random From:. No, it's commentary on the rambling style and mostly irrelevant content of messages from John D. Hendrickson and Sara Darnell. This entity claims to be required to send all its messages to the same mailing list due to some interaction between its own mail server and its ISP's outgoing spam filter. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2022214123.gt3...@decadent.org.uk
Re: Increasing minimum 'i386' processor
Le mardi 22 novembre 2011 à 16:19 -0500, John D. Hendrickson and Sara Darnell a écrit : Josselin Mouette is apparently easily amused. I am afraid that text cannot convey my feelings adequately, so please find here a more appropriate reply: http://malsain.org/~joss/amused.jpg Rest assured that my next contribution to a conversation you are part of might not be for the list but for its masters. Kthxbye, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1322001810.6897.8.camel@tomoyo
Re: Increasing minimum 'i386' processor
Ben Hutchings b...@decadent.org.uk writes: Does /proc/cpuinfo with the exist on non-Linux architectures? If yes, do they use the same format? It is Linux-specific, but included in FreeBSD's Linux compatibility module. I don't know whether Debian kFreeBSD loads that by default. It is loaded. /proc/cpuinfo on field (kfreebsd-i386 buildd): processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 16 model name : Intel(R) Xeon(TM) CPU 3.80GHz stepping: 10 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 16 model name : Intel(R) Xeon(TM) CPU 3.80GHz stepping: 10 processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 16 model name : Intel(R) Xeon(TM) CPU 3.80GHz stepping: 10 processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 16 model name : Intel(R) Xeon(TM) CPU 3.80GHz stepping: 10 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 b19 b21 mmxext mmx fxsr xmm sse2 b27 b28 b29 3dnow cpu MHz : 3800.15 bogomips: 3800.15 It's subjectively quite different from linux/x86 but the same is true for e.g. s390 Regards Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lir73gx4@hepworth.siccegge.de
Re: Increasing minimum 'i386' processor
On 11/19/2011 11:42 PM, Ben Hutchings wrote: The i386 architecture was the first in Linux and in Debian, but we have long since dropped support for the original i386-compatible processors and now require a minimum of a 486-class processor. I think it is time to increase the minimum requirement to 586-class, if not for wheezy then immediately after. note that squeeze is built this way, and single packages like openjdk only build for 586. (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) This would allow the use of optimisations and new instructions throughout userland that improve performance for the vast majority of users. could you give numbers what kind of improvements you would expect? The biggest burden for i386 is the register pressure, which you won't fix with targeting a newer processor. The better approach would be a new port, the x32 architecture; I don't know if anybody did look into building a distribution for this architecture yet. The next thing could be to default to sse2 math instead of x87 (didn't look if this is already the default for x32). Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ecc33cd.7040...@debian.org
Re: Increasing minimum 'i386' processor
On 11/20/2011 01:08 AM, Guillem Jover wrote: Hi! On Sat, 2011-11-19 at 22:42:11 +, Ben Hutchings wrote: The i386 architecture was the first in Linux and in Debian, but we have long since dropped support for the original i386-compatible processors and now require a minimum of a 486-class processor. I think it is time to increase the minimum requirement to 586-class, if not for wheezy then immediately after. (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) This would allow the use of optimisations and new instructions throughout userland that improve performance for the vast majority of users. It seems gcc has been targetting i586 instruction set by default since gcc 4.4.0-1~exp1, although the triplet was not changed to match. On the discussion regarding multiarch tuples I proposed we should switch the triplet back to i386-linux-gnu to avoid this kind of confusion, fix the internal inconsistency and the one with other architectures (which do not track the base instruction set in the triplet) and so that we can use them directly as the multiarch tuples. For more details please see: http://lists.debian.org/debian-dpkg/2011/02/msg00061.html http://lists.debian.org/debian-dpkg/2011/02/msg00039.html No, that's wrong. i386-linux-gnu has a different ABI for at least some libraries (libstdc++) than i486-linux-gnu. Unfortunately the proposal to use ix86-linux-gnu for the i386 multiarch triplet didn't find a consensus. Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ecc34e9.6090...@debian.org
Re: Increasing minimum 'i386' processor
Hi, On Montag, 21. November 2011, Ben Hutchings wrote: Maybe you think it's a waste to replace old PCs, but in many cases it's a waste of money to keep them running. Electricity isn't getting any cheaper and modern systems are much better at power-saving. This is true, but not everywhere on on earth. Very old systems are still in use in many parts of the world today and will be. So I like the idea of using multiarch to be able continue to support them. universal os, blabla ;) cheers, Holger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20211028.51391.hol...@layer-acht.org
Re: Increasing minimum 'i386' processor
On Mon, 21 Nov 2011, Ben Hutchings b...@decadent.org.uk wrote: I think that would be a pity if Debian will not provide anymore a kernel for this old cpus. Maybe you think it's a waste to replace old PCs, but in many cases it's a waste of money to keep them running. Electricity isn't getting any cheaper and modern systems are much better at power-saving. http://doc.coker.com.au/environment/computer-power-use/ From systems I've tested it seems that the trend has generally been towards increased power use. Core 2 systems use about half the power of a Pentium-D system but that's more related to how bad then Pentium-D was than anything else. My old Cobolt Qube took less power than any other non-laptop I tested and the P3 desktop systems I still use as low-end servers beat anything else I can get for free. In terms of CPU features the least capable system I run is now my EeePC 701 and it seems that you aren't planning to drop support for that. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20212109.58475.russ...@coker.com.au
Re: Increasing minimum 'i386' processor
Hi Russel, On Mon, Nov 21, 2011 at 09:09:58PM +1100, Russell Coker wrote: On Mon, 21 Nov 2011, Ben Hutchings b...@decadent.org.uk wrote: I think that would be a pity if Debian will not provide anymore a kernel for this old cpus. Maybe you think it's a waste to replace old PCs, but in many cases it's a waste of money to keep them running. Electricity isn't getting any cheaper and modern systems are much better at power-saving. http://doc.coker.com.au/environment/computer-power-use/ From systems I've tested it seems that the trend has generally been towards increased power use. Core 2 systems use about half the power of a Pentium-D system but that's more related to how bad then Pentium-D was than anything else. well, its obvious that the *absolute* power consumption, which is what you measure, has increased, given that the performance of the systems has increased as well. Measuring absolute values is all nice to compare the effective cost of running a system, but it does neither support nor weaken the point that modern systems are much better at power-saving. Also to actually draw any conclusion from your statistics, one would need to know more about the hardware in question. Especially its unclear weither the PSUs used in the systems all have the same efficency. -Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2021121356.GA10017@debian
Re: Increasing minimum 'i386' processor
On Mon, 21 Nov 2011, Patrick Schoenfeld schoenf...@debian.org wrote: well, its obvious that the absolute power consumption, which is what you measure, has increased, given that the performance of the systems has increased as well. If you are setting up a network of machines for bitcoin mining then it's most likely that modern systems would give the best value for money. Measuring absolute values is all nice to compare the effective cost of running a system, but it does neither support nor weaken the point that modern systems are much better at power-saving. If you have tasks which require little CPU power (such as a DNS server) and the system is idle most of the time then comparing the idle power use is the most important thing. Another example is the Internet gateway system I use. It's a P3-800 and I have no plans to upgrade it because it can handle higher speeds than my ADSL link and that's all that is required. Also to actually draw any conclusion from your statistics, one would need to know more about the hardware in question. Especially its unclear weither the PSUs used in the systems all have the same efficency. Whether the PSUs are of the same efficiency doesn't matter much as the options for switching them are limited. In the unlikely event that the P3 class desktop PCs I tested gave better results than Pentium-D and other newer systems because of having better PSUs it wouldn't matter as the newer systems need SATA connectors and an extra 4 pins on the motherboard connector. But I don't expect that PSUs have become less efficient, if anything I would expect them to have improved slightly in recent times. Maybe a P3 system would use even less power if it had a PSU taken from a newer system such as a Pentium-D. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20212330.23307.russ...@coker.com.au
Re: Increasing minimum 'i386' processor
Hi, On Mon, Nov 21, 2011 at 11:30:22PM +1100, Russell Coker wrote: On Mon, 21 Nov 2011, Patrick Schoenfeld schoenf...@debian.org wrote: well, its obvious that the absolute power consumption, which is what you measure, has increased, given that the performance of the systems has increased as well. If you are setting up a network of machines for bitcoin mining then it's most likely that modern systems would give the best value for money. Measuring absolute values is all nice to compare the effective cost of running a system, but it does neither support nor weaken the point that modern systems are much better at power-saving. If you have tasks which require little CPU power (such as a DNS server) and the system is idle most of the time then comparing the idle power use is the most important thing. Uhm.. yes, its the most important thing for you to decide weither the system is over-sized for a job that could eventually be very well be done by a atom system or even some low performance embedded system. However it does not qualify for a *general* assesment weither modern systems have become better at power-saving or, because its still not comparable. If you really do not need the extra power, you are still able to buy a modern but less powerful system, like lets say an Atom. You can compare that machines to draw a usefull assesment. Another example is the Internet gateway system I use. It's a P3-800 and I have no plans to upgrade it because it can handle higher speeds than my ADSL link and that's all that is required. Same as above: Its not like you are forced to use a P3-800 or a even more over-sized system for that purpose. An atom might fit and will have less power consumption. Also to actually draw any conclusion from your statistics, one would need to know more about the hardware in question. Especially its unclear weither the PSUs used in the systems all have the same efficency. Whether the PSUs are of the same efficiency doesn't matter much as the options for switching them are limited. No, the options for switching them are totally unrelated to a comparison of the absolut power consumption. In the unlikely event that the P3 class desktop PCs I tested gave better results than Pentium-D and other newer systems because of having better PSUs it wouldn't matter as the newer systems need SATA connectors and an extra 4 pins on the motherboard connector. The point is not weither you can change the PSU of a P3 with the PSU of an Pentium-D or newer. The point is weither a Pentium D with a better Pentium D-suitable PSU would have given different results. (or same vice versa) Because, today you can chose between PSUs which (usually) vary between 70% and 90% efficiency. Dunno what efficiency previous PSUs had. So if your P3 might happen to have a PSU with an efficiency of 90%, while your Pentium-D has an efficiency of 70%, this *will* result in a significant difference in comparibility of the two values. But I don't expect that PSUs have become less efficient, if anything I would expect them to have improved slightly in recent times. Maybe a P3 system would use even less power if it had a PSU taken from a newer system such as a Pentium-D. Well, while that is your expectation, you did not back it with facts and therefore we need to assume that this expectation is false. -Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2021132012.GB10017@debian
Re: Increasing minimum 'i386' processor
On Tue, 22 Nov 2011, Patrick Schoenfeld schoenf...@debian.org wrote: If you have tasks which require little CPU power (such as a DNS server) and the system is idle most of the time then comparing the idle power use is the most important thing. Uhm.. yes, its the most important thing for you to decide weither the system is over-sized for a job that could eventually be very well be done by a atom system or even some low performance embedded system. However it does not qualify for a *general* assesment weither modern systems have become better at power-saving or, because its still not comparable. If you really do not need the extra power, you are still able to buy a modern but less powerful system, like lets say an Atom. You can compare that machines to draw a usefull assesment. People save power to save money, to save cooling, or to save the environment. Buying new hardware isn't the way to save money, power is cheap enough in most places that the cost of a new Atom system would cover 4+ years of running a P3. Cooling can be an issue, but usually only in a DC where computational density is the most important issue and therefore multi-core 64bit CPUs win. For saving the environment it's a really good thing to avoid buying new systems. The point is not weither you can change the PSU of a P3 with the PSU of an Pentium-D or newer. The point is weither a Pentium D with a better Pentium D-suitable PSU would have given different results. (or same vice versa) Because, today you can chose between PSUs which (usually) vary between 70% and 90% efficiency. Dunno what efficiency previous PSUs had. So if your P3 might happen to have a PSU with an efficiency of 90%, while your Pentium-D has an efficiency of 70%, this *will* result in a significant difference in comparibility of the two values. The difference in recorded power use between my Pentium-D system and one of the more efficient P3 systems is a factor of 3. A 70%-90% PSU efficiency difference will not impact that. Well, while that is your expectation, you did not back it with facts and therefore we need to assume that this expectation is false. So far I've been the only person in this discussion to supply any facts about power use of various systems. Feel free to provide reference to facts that you think are relevant. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20220029.01693.russ...@coker.com.au
Re: Increasing minimum 'i386' processor
On Mon, 2011-11-21 at 21:09 +1100, Russell Coker wrote: On Mon, 21 Nov 2011, Ben Hutchings b...@decadent.org.uk wrote: I think that would be a pity if Debian will not provide anymore a kernel for this old cpus. Maybe you think it's a waste to replace old PCs, but in many cases it's a waste of money to keep them running. Electricity isn't getting any cheaper and modern systems are much better at power-saving. http://doc.coker.com.au/environment/computer-power-use/ From systems I've tested it seems that the trend has generally been towards increased power use. Core 2 systems use about half the power of a Pentium-D system but that's more related to how bad then Pentium-D was than anything else. [...] Try comparing some of the ARM systems that can run Debian. Ben. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else. signature.asc Description: This is a digitally signed message part
Re: Increasing minimum 'i386' processor
On Tue, Nov 22, 2011 at 12:29:01AM +1100, Russell Coker wrote: People save power to save money, to save cooling, or to save the environment. Right, but far from relevant when comparing old systems to new systems in terms of power saving. Buying new hardware isn't the way to save money , power is cheap enough in most places that the cost of a new Atom system would cover 4+ years of running a P3. Cooling can be an issue, but usually only in a DC where computational density is the most important issue and therefore multi-core 64bit CPUs win. For saving the environment it's a really good thing to avoid buying new systems. Well, its not like your more modern systems fell from heaven. At the point where you bought them, you eventually had all options to buy less power consuming hardware, yet you didn't. But we are really moving far to far away from the original discussion. The point is not weither you can change the PSU of a P3 with the PSU of an Pentium-D or newer. The point is weither a Pentium D with a better Pentium D-suitable PSU would have given different results. (or same vice versa) Because, today you can chose between PSUs which (usually) vary between 70% and 90% efficiency. Dunno what efficiency previous PSUs had. So if your P3 might happen to have a PSU with an efficiency of 90%, while your Pentium-D has an efficiency of 70%, this *will* result in a significant difference in comparibility of the two values. The difference in recorded power use between my Pentium-D system and one of the more efficient P3 systems is a factor of 3. A 70%-90% PSU efficiency difference will not impact that. Come on. All I was saying is that the values cannot be compared, because its unsure weither they are based on comparable hardware or not. Picking _one_ example from your test sample will not disprove that claim. Apart from that, I said that your stats miss more information than just the efficiency of the PSU. Another one would be what a PSU is actually used, because its a fact that the energy efficiency of power supplies drops significantly at low loads, so it might even be important weither a 200W, 300W or 400W PSU was chosen. You say that your PSUs are designed for small loads, but what exactly does that mean? What about the graphics cards of the systems? Low-end card or does one of the systems probably have a high-end gaming ghraphics cards which takes 30-60W on its own? Well, while that is your expectation, you did not back it with facts and therefore we need to assume that this expectation is false. So far I've been the only person in this discussion to supply any facts about power use of various systems. Yeah and thats fine, I just want to point out, that your facts have to be taken with care when trying to make an assesment for a distribution-wide decision. Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2021142641.GA12651@debian
Re: Increasing minimum 'i386' processor
On Mon, Nov 21, 2011 at 07:48:30AM +0100, Mike Hommey wrote: On Sun, Nov 20, 2011 at 01:58:53PM -0800, Steve Langasek wrote: On Sun, Nov 20, 2011 at 08:48:08PM +, Ben Hutchings wrote: Would it be worth adding a lintian check for instructions that may not be supported (bearing in mind that a fair few packages will need to override it)? I've wanted this for a while, but haven't been sure how to go about it. I would even favor making this an overrideable archive reject tag, for use of cmov outside of a hwcap directory. Something similar on armel (armv4t vs. armv7) and powerpc (altivec) would probably be worthwhile. ... and that will fail to find the legitimate uses that are conditional on the appropriate hardware support at runtime. Yes, that's why it should be an overridable archive reject instead of a mandatory one. But we do get packages with wrong code in the archive from time to time, and I think it would be good to have a higher bar for these accidentally-wrong packages. I guess you disagree? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
486 still being sold NEW / was Re: Increasing minimum 'i386' processor
On Sun, 20 Nov 2011, Ben Hutchings wrote: On Sun, 2011-11-20 at 16:30 +0100, Kai Wasserbäch wrote: [..] Apart from that I wonder how many embedded x86 CPUs (instruction set 586) are out there. Are they still sold in current products? As I said, Soekris still seems to have some for sale, but they are just using up their remaining stock of CPUs. There still is a rather large market for 486-class systems, it's just not very visible to the average consumer. It's the industrial PCs (IPC), for example the PC/104 form factor. The first google page gives this: http://www.prinser.com/SearchResult.aspx?CategoryID=25 http://www.emacinc.com/sbc_pc.htm#486sbc http://www.aton-sys.fr/English/produits/liste_tous.htm http://www.cpuboards.com/cpu-boards/bus-interface-pc-104 Granted, they're not powerful (they don't need to be), but they're still being produced(!) and sold, and they are a very interesting target for a Debian environment. Now personally I'm not running these and I don't care much about 486 systems, but I'd say that any dropping of support for these industrial boards should be considered really carefully. Best regards, Anne Bezemer
Re: Increasing minimum 'i386' processor
On Sun, Nov 20, 2011 at 11:44:38PM +0100, Cesare Leonardi wrote: These processors are about 15 years old but are still useful and usable today and maybe still for Wheezy+1. Bear in mind that when wheezy+1 is released, wheezy will still be supported for some time. So the *actual* time that Debian removes support for this 15 year old chip would be after the release of wheezy+1. Also remember that you can continue to run an older release of Debian on old hardware, particularly if such old hardware is doing a relatively static job (such as routing), after stable support has ended. After that point, you can hand-backport things that you care about enough, for security coverage. I think that would be a pity if Debian will not provide anymore a kernel for this old cpus. I think it would be a pity if Debian was held back to support such a tiny minority of potential users. -- Jon Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2021155805.GE20925@pris
Re: Increasing minimum 'i386' processor
On 2011-11-21, Jon Dowland j...@debian.org wrote: I think it would be a pity if Debian was held back to support such a tiny minority of potential users. Why can't the others use amd64? In theory the audience of the i386 port would be non-64bit capable processors anyway. I know that this includes certain Atoms as well, so I can't just say processors older than those made in the last five years. But I'm not sure if we're actually held back in any way given a superior port like amd64. (And as the multimedia team pointed out in this very thread, you'll get much better optimizations there.) That said at some point we might want to get more performance out of the amd64 port, too. (Like using AVX with hwcaps.) Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjcl13p.r1f.tr...@kelgar.0x539.de
Re: Increasing minimum 'i386' processor
How does one do a simple test to see if one is on the death list? # grep -c 86 /proc/cpuinfo 0 # lshw | grep -c 86 0 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqgl5ok1@jidanni.org
Re: 486 still being sold NEW / was Re: Increasing minimum 'i386' processor
On Mon, Nov 21, 2011 at 04:44:03PM +0100, J.A. Bezemer wrote: On Sun, 20 Nov 2011, Ben Hutchings wrote: On Sun, 2011-11-20 at 16:30 +0100, Kai Wasserbäch wrote: [..] Apart from that I wonder how many embedded x86 CPUs (instruction set 586) are out there. Are they still sold in current products? As I said, Soekris still seems to have some for sale, but they are just using up their remaining stock of CPUs. There still is a rather large market for 486-class systems, it's just not very visible to the average consumer. It's the industrial PCs (IPC), for example the PC/104 form factor. The first google page gives this: [...] Now personally I'm not running these and I don't care much about 486 systems, but I'd say that any dropping of support for these industrial boards should be considered really carefully. Since we're theorising, rather than talking about actual users, my theory is that these are sold as replacements for installed systems, which will run the exact same software as the original - not Debian 7.0. It would be silly to start a new deployment reliant on parts that have already been EOL'd. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2021185227.gp3...@decadent.org.uk
Re: Increasing minimum 'i386' processor
On Tue, Nov 22, 2011 at 02:16:14AM +0800, jida...@jidanni.org wrote: How does one do a simple test to see if one is on the death list? There isn't one (yet). # grep -c 86 /proc/cpuinfo 0 # lshw | grep -c 86 0 This should tell you if the processor supports Pentium features: grep ' tsc msr.* cx8' /proc/cpuinfo Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2021185732.gq3...@decadent.org.uk
Re: Increasing minimum 'i386' processor
On Sun, 20 Nov 2011 23:31:43 +, Ben Hutchings b...@decadent.org.uk wrote: On Sun, 2011-11-20 at 13:58 -0800, Steve Langasek wrote: On Sun, Nov 20, 2011 at 08:48:08PM +, Ben Hutchings wrote: Would it be worth adding a lintian check for instructions that may not be supported (bearing in mind that a fair few packages will need to override it)? I've wanted this for a while, but haven't been sure how to go about it. I would even favor making this an overrideable archive reject tag, for use of cmov outside of a hwcap directory. Something similar on armel (armv4t vs. armv7) and powerpc (altivec) would probably be worthwhile. 1. Find all ELF executable/library files. 2. Either: a. Work out which instructions should be excluded, depending on the directory. b. Skip files in hwcap directories and exclude all instructions missing from the minimum processor. 3. 'objdump -d | grep' with appropriate instruction regexp; fail if there's a match. http://dev.gentoo.org/~dirtyepic/bin/analyze-x86 is very handy for this, although it's quite CPU-intensive. Regards, Stephen signature.asc Description: PGP signature
Re: Increasing minimum 'i386' processor
Ben Hutchings b...@decadent.org.uk writes: On Sun, 2011-11-20 at 23:44 +0100, Cesare Leonardi wrote: […] While i might agree with the exclusion of 486 cpu classes (somewhere i have a Winchip C6 200 MHz but i consider it unusable except for very limited tasks), i think that excluding 586 could be too aggressive. AMD K6-2 processors doesn't have CMOV, because when i try to use various rescue CD on some of these machine, they don't boot with a messages informing of the missing instruction. These processors are about 15 years old but are still useful and usable today and maybe still for Wheezy+1. I think that would be a pity if Debian will not provide anymore a kernel for this old cpus. Maybe you think it's a waste to replace old PCs, but in many cases it's a waste of money to keep them running. Electricity isn't getting any cheaper and modern systems are much better at power-saving. I'm not sure about ARM, but one of my K6-based systems apparently has power consumption below or comparable to that of one of my Intel Atom ones. (Though the performance of the former is obviously lower.) One more observation is that the 80386-based systems and the like didn't require any coolers. That being said, I'm now considering moving to ARM-based hardware, such as the Raspberry Pi computer, for the tasks that don't require much CPU cycles. -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/86k46soboo@gray.siamics.net
Re: Increasing minimum 'i386' processor
Guillem Jover guil...@debian.org writes: Hi! On Sat, 2011-11-19 at 22:42:11 +, Ben Hutchings wrote: The i386 architecture was the first in Linux and in Debian, but we have long since dropped support for the original i386-compatible processors and now require a minimum of a 486-class processor. I think it is time to increase the minimum requirement to 586-class, if not for wheezy then immediately after. (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) This would allow the use of optimisations and new instructions throughout userland that improve performance for the vast majority of users. It seems gcc has been targetting i586 instruction set by default since gcc 4.4.0-1~exp1, although the triplet was not changed to match. On the discussion regarding multiarch tuples I proposed we should switch the triplet back to i386-linux-gnu to avoid this kind of confusion, fix the internal inconsistency and the one with other architectures (which do not track the base instruction set in the triplet) and so that we can use them directly as the multiarch tuples. For more details please see: http://lists.debian.org/debian-dpkg/2011/02/msg00061.html http://lists.debian.org/debian-dpkg/2011/02/msg00039.html regards, guillem While I agree that the triplet should be unique for all the reasons stated in the two mails I have to disagree with your conclusion to change the gcc triplet to i386-linux-gnu. A gcc compiling for i486-linux-gnu, i585-linux-gnu or even i686-linux-gnu is not compiling for the i386-linux-gnu ABI. You would be making the same mistake that arm does on i*86 too, making the triplet not unique. You could have a normal gcc and a i386-linux-gnu-gcc on your system. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5vbf2f8.fsf@frosties.localnet
Re: Increasing minimum 'i386' processor
On Sun, Nov 20, 2011 at 08:40:47AM +0100, Raphael Hertzog wrote: Hi! 6. DMP/SiS Vortex86 and Vortex86SX. These supposedly have all 586-class features except an FPU, and we could probably keep FPU emulation for them. FWIW, I do run Debian on such systems albeit with a custom kernel. Given those CPU tend to be used in an embedded context I guess it's ok if the official kernel does not support them. But it would be nice if Debian's userspace could be kept compatible. On behalf of the multimedia camp, I'd like to point out that we'd love to see SSE as the lowest common denominator on the x86 platform. I'm fully aware that we can't, not even with i586 being the baseline. Since many multimedia applications don't do runtime CPU detection, only amd64 generally provides decent SIMD support to Debian users on x86 these days. Long story short: userspace i386 compatibility would suck for multimedia. ;) Just my €0.02 PS: That's basically why we have packages like ardour-i686. -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2020115655.gq10...@ltw.loris.tv
Re: Increasing minimum 'i386' processor
Le 20/11/2011 12:56, Adrian Knoth a écrit : On behalf of the multimedia camp, I'd like to point out that we'd love to see SSE as the lowest common denominator on the x86 platform. I'm fully aware that we can't, not even with i586 being the baseline. Since many multimedia applications don't do runtime CPU detection, only amd64 generally provides decent SIMD support to Debian users on x86 these days. Long story short: userspace i386 compatibility would suck for multimedia. ;) Partial multi-arch aware architectures would be the perfect answer here. (ie a i686 archive with only package/libs that are improved by using the i686 instruction set) rant on When will dpkg multi-arch aware be available in sid ? rant off Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ec908dd.3060...@free.fr
Re: Increasing minimum 'i386' processor
Adrian Knoth a...@drcomp.erfurt.thur.de writes: On Sun, Nov 20, 2011 at 08:40:47AM +0100, Raphael Hertzog wrote: Hi! 6. DMP/SiS Vortex86 and Vortex86SX. These supposedly have all 586-class features except an FPU, and we could probably keep FPU emulation for them. FWIW, I do run Debian on such systems albeit with a custom kernel. Given those CPU tend to be used in an embedded context I guess it's ok if the official kernel does not support them. But it would be nice if Debian's userspace could be kept compatible. On behalf of the multimedia camp, I'd like to point out that we'd love to see SSE as the lowest common denominator on the x86 platform. I'm fully aware that we can't, not even with i586 being the baseline. Since many multimedia applications don't do runtime CPU detection, only amd64 generally provides decent SIMD support to Debian users on x86 these days. Long story short: userspace i386 compatibility would suck for multimedia. ;) Just my â¬0.02 PS: That's basically why we have packages like ardour-i686. That's why you would have an i686 partial architecture with all the multimedia stuff in there optimized. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjlilwbf.fsf@frosties.localnet
Re: Increasing minimum 'i386' processor
On Nov 20, Adrian Knoth a...@drcomp.erfurt.thur.de wrote: On behalf of the multimedia camp, I'd like to point out that we'd love to see SSE as the lowest common denominator on the x86 platform. Can you show a rough list of the relevant packages? Maybe older CPUs would be too much slow anyway for many of them, so targetting more recent CPUs than the norm would not hurt. -- ciao, Marco signature.asc Description: Digital signature
Re: Increasing minimum 'i386' processor
On Nov 19, Ben Hutchings b...@decadent.org.uk wrote: I think it is time to increase the minimum requirement to 586-class, if not for wheezy then immediately after. I agree, it's time to weight the costs and benefits of supporting obsolete hardware at the expense of most users. (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) Yes, but how much later? :-) -- ciao, Marco signature.asc Description: Digital signature
Re: Increasing minimum 'i386' processor
Dear Ben, Ben Hutchings schrieb am 19.11.2011 23:42: The i386 architecture was the first in Linux and in Debian, but we have long since dropped support for the original i386-compatible processors and now require a minimum of a 486-class processor. I think it is time to increase the minimum requirement to 586-class, if not for wheezy then immediately after. (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) This would allow the use of optimisations and new instructions throughout userland that improve performance for the vast majority of users. I think in time for Wheezy would be fine. People with an older CPU will most likely not have that much fun with newer releases anyway, simply because a lot of programs tend to get bigger and more power-hungry over time. Just out of curiosity: are there any numbers available, indicating how many installations with CPUs with an instruction set 586 are still in use? Does popcon collect such information? Kind regards, Kai Wasserbäch -- E-Mail: cu...@debian.org IRC: Curan Jabber: dri...@debianforum.de URL: http://wiki.debian.org/C%C3%B9ran GnuPG: 0xE1DE59D2 0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2 signature.asc Description: OpenPGP digital signature
Re: Increasing minimum 'i386' processor
Dear Raphaël, Raphaël Hertzog schrieb am 20.11.2011 08:40: On Sat, 19 Nov 2011, Ben Hutchings wrote: Also possibly: 6. DMP/SiS Vortex86 and Vortex86SX. These supposedly have all 586-class features except an FPU, and we could probably keep FPU emulation for them. FWIW, I do run Debian on such systems albeit with a custom kernel. Given those CPU tend to be used in an embedded context I guess it's ok if the official kernel does not support them. But it would be nice if Debian's userspace could be kept compatible. Not sure what this requires though... judging from the section you quoted from Ben's e-mail, I'd say you shouldn't be affected in the short term if the FPU is really the only thing missing to make it a full 586-class CPU (of course, a further increase to a higher instruction set class would hit you). Apart from that I wonder how many embedded x86 CPUs (instruction set 586) are out there. Are they still sold in current products? If so it might(!) be worth to keep compatible with them, even if that would mean an additional kernel build*. On the other hand most embedded kernels are custom build anyway, in which case offering the tools to build a running Debian system should be enough, right? * The question here is (again): do we have some numbers on this, that could guide the decision? If not and the assumption by the kernel maintainers is few systems still operational run with CPUs which don't at least support 586 instructions, then I'd find it reasonable to still disable the support in the kernel. In case a huge amount of systems is still running with such CPUs chances are good, we're hearing of them then. ;-) Kind regards, Kai Wasserbäch -- E-Mail: cu...@debian.org IRC: Curan Jabber: dri...@debianforum.de URL: http://wiki.debian.org/C%C3%B9ran GnuPG: 0xE1DE59D2 0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2 signature.asc Description: OpenPGP digital signature
Re: Increasing minimum 'i386' processor
Kai Wasserbäch cu...@debian.org writes: installations with CPUs with an instruction set 586 are still in use? Does popcon collect such information? popcon does not but smolt does. Unfortunately smotl ITP is still stuck. Meanwhile you can look at the data it has collected from opensuse and fedora users: echo 'select count(*) as c, cpu_model from host group by cpu_model order by c;' | mysql -h localhost -u smoon -p --password=smoon -D smoon p/smolt/cpu_model_count.txt = http://lindi.iki.fi/lindi/smolt/cpu_model_count.txt Full database dump is at http://lindi.iki.fi/lindi/smolt/smolt-2011-08-28.dmp.gz if you want to make your own queries. -Timo -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84d3cmpzuv@sauna.l.org
Re: Increasing minimum 'i386' processor
On Sun, 2011-11-20 at 08:40 +0100, Raphael Hertzog wrote: On Sat, 19 Nov 2011, Ben Hutchings wrote: Also possibly: 6. DMP/SiS Vortex86 and Vortex86SX. These supposedly have all 586-class features except an FPU, and we could probably keep FPU emulation for them. FWIW, I do run Debian on such systems albeit with a custom kernel. Given those CPU tend to be used in an embedded context I guess it's ok if the official kernel does not support them. But it would be nice if Debian's userspace could be kept compatible. Not sure what this requires though... As I said, I think they may still be supportable - the kernel config allows selection of CONFIG_M586TSC and CONFIG_MATH_EMULATION, though whether the result actually works is another matter. Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
Re: Increasing minimum 'i386' processor
On Sun, 2011-11-20 at 15:04 +0100, Vincent Danjean wrote: Le 20/11/2011 12:56, Adrian Knoth a écrit : On behalf of the multimedia camp, I'd like to point out that we'd love to see SSE as the lowest common denominator on the x86 platform. I'm fully aware that we can't, not even with i586 being the baseline. Since many multimedia applications don't do runtime CPU detection, only amd64 generally provides decent SIMD support to Debian users on x86 these days. Long story short: userspace i386 compatibility would suck for multimedia. ;) Partial multi-arch aware architectures would be the perfect answer here. (ie a i686 archive with only package/libs that are improved by using the i686 instruction set) [...] Yes, this does sound like a good answer, though I don't believe dak is ready to support partial architectures yet. We already have the ability to install optimised libraries that are selected automatically by the dynamic linker, but it would be preferable to have them also selected automatically by APT. Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
Re: Increasing minimum 'i386' processor
On Sun, 2011-11-20 at 16:30 +0100, Kai Wasserbäch wrote: Dear Raphaël, Raphaël Hertzog schrieb am 20.11.2011 08:40: On Sat, 19 Nov 2011, Ben Hutchings wrote: Also possibly: 6. DMP/SiS Vortex86 and Vortex86SX. These supposedly have all 586-class features except an FPU, and we could probably keep FPU emulation for them. FWIW, I do run Debian on such systems albeit with a custom kernel. Given those CPU tend to be used in an embedded context I guess it's ok if the official kernel does not support them. But it would be nice if Debian's userspace could be kept compatible. Not sure what this requires though... judging from the section you quoted from Ben's e-mail, I'd say you shouldn't be affected in the short term if the FPU is really the only thing missing to make it a full 586-class CPU (of course, a further increase to a higher instruction set class would hit you). Apart from that I wonder how many embedded x86 CPUs (instruction set 586) are out there. Are they still sold in current products? As I said, Soekris still seems to have some for sale, but they are just using up their remaining stock of CPUs. If so it might(!) be worth to keep compatible with them, even if that would mean an additional kernel build*. No, there will be no additional kernel flavours. The kernel team is generally aiming to cover all supported systems with as few different configurations as possible. Every extra flavour takes substantial space in the archive and time on autobuilders. On the other hand most embedded kernels are custom build anyway, in which case offering the tools to build a running Debian system should be enough, right? * The question here is (again): do we have some numbers on this, that could guide the decision? If not and the assumption by the kernel maintainers is few systems still operational run with CPUs which don't at least support 586 instructions, then I'd find it reasonable to still disable the support in the kernel. In case a huge amount of systems is still running with such CPUs chances are good, we're hearing of them then. ;-) I'm confident there aren't a huge number of systems, but it's really impossible to tell just how many or few there are. Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
Re: Increasing minimum 'i386' processor
On Sun, 2011-11-20 at 15:14 +0100, Marco d'Itri wrote: On Nov 19, Ben Hutchings b...@decadent.org.uk wrote: I think it is time to increase the minimum requirement to 586-class, if not for wheezy then immediately after. I agree, it's time to weight the costs and benefits of supporting obsolete hardware at the expense of most users. (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) Yes, but how much later? :-) At the latest: wheezy+2 (2016): require 686-class with PAE wheezy+4 (2020): i386 is a partial architecture But I think we could be more aggressive than that. Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
Re: Increasing minimum 'i386' processor
On 2011-11-20, Ben Hutchings b...@decadent.org.uk wrote: As I said, I think they may still be supportable - the kernel config allows selection of CONFIG_M586TSC and CONFIG_MATH_EMULATION, though whether the result actually works is another matter. So what are we actually requiring when moving from 486 to 586? From your listing I guess rdtsc and the presence of a x87 FPU (didn't we already require that before?). Anything else? Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjcig4t.nh2.tr...@kelgar.0x539.de
Re: Increasing minimum 'i386' processor
On Sun, 2011-11-20 at 18:02 +, Philipp Kern wrote: On 2011-11-20, Ben Hutchings b...@decadent.org.uk wrote: As I said, I think they may still be supportable - the kernel config allows selection of CONFIG_M586TSC and CONFIG_MATH_EMULATION, though whether the result actually works is another matter. So what are we actually requiring when moving from 486 to 586? From your listing I guess rdtsc and the presence of a x87 FPU (didn't we already require that before?). Anything else? We don't yet require a real FPU as not all 486-class processors have them. The new Pentium instructions are (according to Dr Dobb's http://drdobbs.com/embedded-systems/184409161#0042_000c): CMPXCHG8B - Compare and Exchange 8 Bytes With the LOCK prefix, this provides an atomic double-word compare-and- exchange. Some lock-free multithreaded algorithms are impossible to implement in userland without this operation. The kernel can fall back to an alternate that disables interrupts temporarily and this is done by patching at boot time. Requiring CMPXCHG8B would reduce the kernel image size very slightly. RDTSC - Read Time Stamp Counter This is often used in performance-sensitive code, though it is hard to use correctly in userland due to preemption and variable frequency on older processors. The kernel makes heavy use of this for precise timing, if possible. If we require a TSC, some run-time checks are removed but the kernel still cannot use it unconditionally due to flaws in some implementations. CPUID - CPU Identification This is not (in itself) important to performance. Earlier processors can be identified through other means and the most useful information is already exposed to userland through /proc/cpuinfo. The kernel always checks whether CPUID is available before using it. RDMSR - Read from Model Specific Register WRMSR - Write to Model Specific Register RSM - Resume from System Management Mode MOV - Move to/from Control Registers These are only useful to the kernel and/or firmware and would be used where necessary regardless of the supported processors. So far as I'm aware, none of the above will be generated directly by compilers (though they may be available through 'intrinsics'). So it may be that there is little to be gained by moving to 586-class as a minimum. If that is so, we should instead think forward to 686-class with CMOV as a minimum for wheezy + 1. Use of CMOV instructions is an important optimisation and they *are* generated directly by compilers. Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
Re: Increasing minimum 'i386' processor
On Sun, Nov 20, 2011 at 07:36:43PM +, Ben Hutchings wrote: So far as I'm aware, none of the above will be generated directly by compilers (though they may be available through 'intrinsics'). So it may be that there is little to be gained by moving to 586-class as a minimum. If that is so, we should instead think forward to 686-class with CMOV as a minimum for wheezy + 1. Use of CMOV instructions is an important optimisation and they *are* generated directly by compilers. And I think gcc already generates cmov instructions. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2020202955.ga7...@roeckx.be
Re: Increasing minimum 'i386' processor
Interestingly, I found the following libraries on a current 'unstable' system already using 586 instructions and not installed in an appropriate subdirectory: /lib/i386-linux-gnu/libgcrypt.so.11.7.0: cpuid /usr/lib/i386-linux-gnu/i486/libcrypto.so.1.0.0: cpuid /usr/lib/i386-linux-gnu/i486/libcrypto.so.1.0.0: rdtsc /usr/lib/i386-linux-gnu/libavutil.so.51.7.0: cpuid /usr/lib/i386-linux-gnu/libavutil.so.51.7.0: rdtsc /usr/lib/i386-linux-gnu/libgcj.so.10.0.0: cmpxchg8b /usr/lib/i386-linux-gnu/libgcj.so.12.0.0: cmpxchg8b /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2400.0: cpuid /usr/lib/i386-linux-gnu/libgmp.so.10.0.2: cpuid /usr/lib/i386-linux-gnu/libjack.so.0.0.28: rdtsc /usr/lib/i386-linux-gnu/libmp3lame.so.0.0.0: cpuid /usr/lib/i386-linux-gnu/libpixman-1.so.0.24.0: cpuid /usr/lib/i386-linux-gnu/libvisual-0.4.so.0.0.0: cpuid /usr/lib/i486/libcrypto.so.0.9.8: cpuid /usr/lib/i486/libcrypto.so.0.9.8: rdtsc /usr/lib/libavcodec.so.52.72.2: cpuid /usr/lib/libavutil.so.50.15.1: rdtsc /usr/lib/libbabl-0.0.so.0.22.0: cpuid /usr/lib/libcrypto.so.0.9.8: cpuid /usr/lib/libcrypto++.so.9.0.0: cpuid /usr/lib/libdirectfb-1.2.so.9.0.1: cpuid /usr/lib/libdjvulibre.so.21.3.0: cpuid /usr/lib/libdv.so.4.0.3: cpuid /usr/lib/libfftw3f.so.3.2.4: cpuid /usr/lib/libfftw3f.so.3.2.4: rdtsc /usr/lib/libfftw3l.so.3.2.4: rdtsc /usr/lib/libfftw3.so.3.2.4: cpuid /usr/lib/libfftw3.so.3.2.4: rdtsc /usr/lib/libgegl-0.0.so.0.22.0: cpuid /usr/lib/libgimpbase-2.0.so.0.600.11: cpuid /usr/lib/libjavascriptcoregtk-1.0.so.0.11.0: cpuid /usr/lib/libjavascriptcoregtk-3.0.so.0.11.0: cpuid /usr/lib/libmozjs.so.6d: cpuid /usr/lib/libmozjs.so.7d: cpuid /usr/lib/libmozjs.so.8d: cpuid /usr/lib/libmpg123.so.0.25.1: cpuid /usr/lib/libmysqlclient_r.so.16.0.0: cpuid /usr/lib/libmysqlclient.so.16.0.0: cpuid /usr/lib/liborc-0.4.so.0.16.0: cpuid /usr/lib/liborc-test-0.4.so.0.16.0: rdtsc /usr/lib/libQtCore.so.4.7.3: cpuid /usr/lib/libQtScript.so.4.7.3: cpuid /usr/lib/libQtTest.so.4.7.3: rdtsc /usr/lib/libQtWebKit.so.4.8.0: cpuid /usr/lib/librpm.so.2.0.2: cpuid /usr/lib/libSDL-1.2.so.0.11.3: cpuid /usr/lib/libtheoradec.so.1.1.4: cpuid /usr/lib/libtheoraenc.so.1.1.2: cpuid /usr/lib/libtheora.so.0.3.10: cpuid /usr/lib/libvirt.so.0.9.7: cpuid /usr/lib/libvlccore.so.4.0.3: cpuid /usr/lib/libvpx.so.0.9.7: cpuid Use of CPUID is probably safe in practice since most 486 models do implement it, though userland should really read /proc/cpuinfo. The other uses may be conditional on a CPU feature test but may well be bugs. Also, the following are using CMOV: /usr/lib/i386-linux-gnu/libasound.so.2.0.0: cmov /usr/lib/i386-linux-gnu/libavcodec.so.53.5.0: cmov /usr/lib/i386-linux-gnu/libgmp.so.10.0.2: cmov /usr/lib/libcrypto++.so.9.0.0: cmov /usr/lib/libmysqlclient_r.so.16.0.0: cmov /usr/lib/libmysqlclient.so.16.0.0: cmov - These all have run-time checks. /usr/lib/i386-linux-gnu/libpixman-1.so.0.24.0: cmov - This either has a run-time check or fails to use the optimised code at all (I don't see how it's reachable). /usr/lib/libgegl-0.0.so.0.22.0: cmov - This seems to be a bug; gegl has been compiled with -mmmx -msse and the latter option implies CMOV can be used since all processors with SSE also have CMOV. /usr/lib/libQtGui.so.4.7.3: cmov - I didn't feel like downloading the source, so haven't checked this. /usr/lib/libxenstore.so.3.0.0: cmov - The hypervisor itself requires a 686-class processor, so not a serious problem. Would it be worth adding a lintian check for instructions that may not be supported (bearing in mind that a fair few packages will need to override it)? Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
Re: Increasing minimum 'i386' processor
On Sun, 2011-11-20 at 21:29 +0100, Kurt Roeckx wrote: On Sun, Nov 20, 2011 at 07:36:43PM +, Ben Hutchings wrote: So far as I'm aware, none of the above will be generated directly by compilers (though they may be available through 'intrinsics'). So it may be that there is little to be gained by moving to 586-class as a minimum. If that is so, we should instead think forward to 686-class with CMOV as a minimum for wheezy + 1. Use of CMOV instructions is an important optimisation and they *are* generated directly by compilers. And I think gcc already generates cmov instructions. Not by default on i386. Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
Re: Increasing minimum 'i386' processor
Hi Ben, On Sun, Nov 20, 2011 at 08:48:08PM +, Ben Hutchings wrote: Would it be worth adding a lintian check for instructions that may not be supported (bearing in mind that a fair few packages will need to override it)? I've wanted this for a while, but haven't been sure how to go about it. I would even favor making this an overrideable archive reject tag, for use of cmov outside of a hwcap directory. Something similar on armel (armv4t vs. armv7) and powerpc (altivec) would probably be worthwhile. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Increasing minimum 'i386' processor
On 20/11/2011 20:36, Ben Hutchings wrote: If that is so, we should instead think forward to 686-class with CMOV as a minimum for wheezy + 1. Use of CMOV instructions is an important optimisation and they *are* generated directly by compilers. While i might agree with the exclusion of 486 cpu classes (somewhere i have a Winchip C6 200 MHz but i consider it unusable except for very limited tasks), i think that excluding 586 could be too aggressive. AMD K6-2 processors doesn't have CMOV, because when i try to use various rescue CD on some of these machine, they don't boot with a messages informing of the missing instruction. These processors are about 15 years old but are still useful and usable today and maybe still for Wheezy+1. I think that would be a pity if Debian will not provide anymore a kernel for this old cpus. Cesare. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ec982d6.9060...@gmail.com
Re: Increasing minimum 'i386' processor
On Sun, 2011-11-20 at 13:58 -0800, Steve Langasek wrote: Hi Ben, On Sun, Nov 20, 2011 at 08:48:08PM +, Ben Hutchings wrote: Would it be worth adding a lintian check for instructions that may not be supported (bearing in mind that a fair few packages will need to override it)? I've wanted this for a while, but haven't been sure how to go about it. I would even favor making this an overrideable archive reject tag, for use of cmov outside of a hwcap directory. Something similar on armel (armv4t vs. armv7) and powerpc (altivec) would probably be worthwhile. 1. Find all ELF executable/library files. 2. Either: a. Work out which instructions should be excluded, depending on the directory. b. Skip files in hwcap directories and exclude all instructions missing from the minimum processor. 3. 'objdump -d | grep' with appropriate instruction regexp; fail if there's a match. Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
Re: Increasing minimum 'i386' processor
Ben's right if he needs it, 386 has many interesting img and tfpt alternatives. Down the road, maybe again. ahh those 386 days! --=20 spam man Official: you owe $100 penalty to your State, send it now or face action. Send it to me ok? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ec9b3d5.4080...@cox.net
Re: Increasing minimum 'i386' processor
On Sun, 2011-11-20 at 23:44 +0100, Cesare Leonardi wrote: On 20/11/2011 20:36, Ben Hutchings wrote: If that is so, we should instead think forward to 686-class with CMOV as a minimum for wheezy + 1. Use of CMOV instructions is an important optimisation and they *are* generated directly by compilers. While i might agree with the exclusion of 486 cpu classes (somewhere i have a Winchip C6 200 MHz but i consider it unusable except for very limited tasks), i think that excluding 586 could be too aggressive. AMD K6-2 processors doesn't have CMOV, because when i try to use various rescue CD on some of these machine, they don't boot with a messages informing of the missing instruction. These processors are about 15 years old but are still useful and usable today and maybe still for Wheezy+1. I think that would be a pity if Debian will not provide anymore a kernel for this old cpus. Maybe you think it's a waste to replace old PCs, but in many cases it's a waste of money to keep them running. Electricity isn't getting any cheaper and modern systems are much better at power-saving. Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
Re: Increasing minimum 'i386' processor
On Sun, Nov 20, 2011 at 01:58:53PM -0800, Steve Langasek wrote: Hi Ben, On Sun, Nov 20, 2011 at 08:48:08PM +, Ben Hutchings wrote: Would it be worth adding a lintian check for instructions that may not be supported (bearing in mind that a fair few packages will need to override it)? I've wanted this for a while, but haven't been sure how to go about it. I would even favor making this an overrideable archive reject tag, for use of cmov outside of a hwcap directory. Something similar on armel (armv4t vs. armv7) and powerpc (altivec) would probably be worthwhile. ... and that will fail to find the legitimate uses that are conditional on the appropriate hardware support at runtime. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2021064830.gb3...@glandium.org
Re: Increasing minimum 'i386' processor
Ben Hutchings b...@decadent.org.uk writes: 5. AMD/NSC Geode GX1, Geode SC1100, Elan SC4xx and SC5xx Does this mean that AMD Geode LX as mentioned in http://pcengines.ch/alix.htm still works? damager:~$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 10 model name : Geode(TM) Integrated Processor by AMD PCS stepping: 2 cpu MHz : 498.026 cache size : 128 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow up bogomips: 996.05 clflush size: 32 cache_alignment : 32 address sizes : 32 bits physical, 32 bits virtual power management: -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84hb1zpvsr@sauna.l.org
Re: Increasing minimum 'i386' processor
On Sun, 2011-11-20 at 00:55 +0200, Timo Juhani Lindfors wrote: Ben Hutchings b...@decadent.org.uk writes: 5. AMD/NSC Geode GX1, Geode SC1100, Elan SC4xx and SC5xx Does this mean that AMD Geode LX as mentioned in http://pcengines.ch/alix.htm still works? [...] Yes, the later 'Geode' processors are 686-class. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Re: Increasing minimum 'i386' processor
Hi! On Sat, 2011-11-19 at 22:42:11 +, Ben Hutchings wrote: The i386 architecture was the first in Linux and in Debian, but we have long since dropped support for the original i386-compatible processors and now require a minimum of a 486-class processor. I think it is time to increase the minimum requirement to 586-class, if not for wheezy then immediately after. (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) This would allow the use of optimisations and new instructions throughout userland that improve performance for the vast majority of users. It seems gcc has been targetting i586 instruction set by default since gcc 4.4.0-1~exp1, although the triplet was not changed to match. On the discussion regarding multiarch tuples I proposed we should switch the triplet back to i386-linux-gnu to avoid this kind of confusion, fix the internal inconsistency and the one with other architectures (which do not track the base instruction set in the triplet) and so that we can use them directly as the multiarch tuples. For more details please see: http://lists.debian.org/debian-dpkg/2011/02/msg00061.html http://lists.debian.org/debian-dpkg/2011/02/msg00039.html regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/202810.ga20...@gaara.hadrons.org
Re: Increasing minimum 'i386' processor
On Sat, 19 Nov 2011, Ben Hutchings wrote: Also possibly: 6. DMP/SiS Vortex86 and Vortex86SX. These supposedly have all 586-class features except an FPU, and we could probably keep FPU emulation for them. FWIW, I do run Debian on such systems albeit with a custom kernel. Given those CPU tend to be used in an embedded context I guess it's ok if the official kernel does not support them. But it would be nice if Debian's userspace could be kept compatible. Not sure what this requires though... Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/go/ulule-rh/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2020074047.gi3...@rivendell.home.ouaza.com
