Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #8050 > unrolled thread
| Started by | Peter Percival <peterxpercival@hotmail.com> |
|---|---|
| First post | 2013-05-09 20:09 +0100 |
| Last post | 2013-06-25 12:52 +0100 |
| Articles | 20 on this page of 147 — 31 participants |
Back to article view | Back to comp.os.linux.misc
Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-05-09 20:09 +0100
Re: Wish to try Linux Jean-David Beyer <jeandavid8@verizon.net> - 2013-05-09 15:25 -0400
Re: Wish to try Linux Robert Heller <heller@deepsoft.com> - 2013-05-09 15:24 -0500
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-09 21:51 +0100
Re: Wish to try Linux Jean-David Beyer <jeandavid8@verizon.net> - 2013-05-09 18:41 -0400
Re: Wish to try Linux Dan Espen <despen@verizon.net> - 2013-05-09 15:28 -0400
Re: Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-05-10 16:48 +0100
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-09 20:48 +0100
Re: Wish to try Linux Octothorpe <Octothorpe@invalid.com> - 2013-05-09 16:45 -0400
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-09 23:50 +0100
Re: Wish to try Linux Octothorpe <Octothorpe@invalid.com> - 2013-05-10 07:41 -0400
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-10 13:01 +0100
Re: Wish to try Linux Octothorpe <Octothorpe@invalid.com> - 2013-05-10 08:49 -0400
Re: Wish to try Linux Aragorn <stryder@telenet.be.invalid> - 2013-05-10 15:20 +0200
Re: Wish to try Linux Octothorpe <Octothorpe@invalid.com> - 2013-05-10 16:11 -0400
Re: Wish to try Linux Jean-David Beyer <jeandavid8@verizon.net> - 2013-05-10 08:04 -0400
Re: Wish to try Linux Bill Marcum <bill@nowhere.invalid> - 2013-05-16 07:58 -0400
Re: Wish to try Linux Bill Marcum <bill@nowhere.invalid> - 2013-05-16 07:56 -0400
Re: Wish to try Linux Octothorpe <Octothorpe@invalid.com> - 2013-05-16 09:32 -0400
Re: Wish to try Linux Aragorn <thorongil@telenet.be.invalid> - 2013-05-16 16:03 +0200
Re: Wish to try Linux John Hasler <jhasler@newsguy.com> - 2013-05-16 09:27 -0500
Re: Wish to try Linux Octothorpe <Octothorpe@invalid.com> - 2013-05-16 10:53 -0400
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-16 15:30 +0100
Re: Wish to try Linux Octothorpe <Octothorpe@invalid.com> - 2013-05-16 10:52 -0400
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-16 15:30 +0100
Re: Wish to try Linux Jean-David Beyer <jeandavid8@verizon.net> - 2013-05-16 16:14 -0400
Re: Wish to try Linux Octothorpe <Octothorpe@invalid.com> - 2013-05-16 17:23 -0400
Re: Wish to try Linux notbob <notbob@nothome.com> - 2013-05-09 23:49 +0000
Re: Wish to try Linux Robert Heller <heller@deepsoft.com> - 2013-05-09 19:35 -0500
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-10 05:30 +0100
Re: Wish to try Linux notbob <notbob@nothome.com> - 2013-05-10 14:27 +0000
Re: Wish to try Linux Michael Black <et472@ncf.ca> - 2013-05-09 22:13 -0400
Re: Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-05-10 16:50 +0100
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-10 17:19 +0100
Re: Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-05-15 16:27 +0100
Re: Wish to try Linux J G Miller <miller@yoyo.ORG> - 2013-05-15 16:34 +0000
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-15 17:46 +0100
Re: Wish to try Linux J G Miller <miller@yoyo.ORG> - 2013-05-15 18:15 +0000
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-15 19:32 +0100
Re: Wish to try Linux Dan Espen <despen@verizon.net> - 2013-05-15 14:52 -0400
Re: Wish to try Linux J G Miller <miller@yoyo.ORG> - 2013-05-15 21:11 +0000
Re: Wish to try Linux Robert Heller <heller@deepsoft.com> - 2013-05-15 13:54 -0500
Re: Wish to try Linux Jean-David Beyer <jeandavid8@verizon.net> - 2013-05-16 01:01 -0400
Re: Wish to try Linux Aragorn <thorongil@telenet.be.invalid> - 2013-05-16 10:52 +0200
Re: Wish to try Linux Jean-David Beyer <jeandavid8@verizon.net> - 2013-05-16 08:25 -0400
Re: Wish to try Linux J G Miller <miller@yoyo.ORG> - 2013-05-16 18:56 +0000
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-16 20:33 +0100
Re: Wish to try Linux J G Miller <miller@yoyo.ORG> - 2013-05-16 19:35 +0000
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-16 20:43 +0100
Re: Wish to try Linux bruce.sinclair@NOSPAMORELSEagresearch.NOTco.NOTnz (Bruce Sinclair) - 2013-05-19 23:33 +0000
Re: Wish to try Linux Jean-David Beyer <jeandavid8@verizon.net> - 2013-05-16 16:16 -0400
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-15 17:44 +0100
Re: Wish to try Linux Robert Heller <heller@deepsoft.com> - 2013-05-15 13:44 -0500
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-15 20:37 +0100
Re: Wish to try Linux "Chris F.A. Johnson" <cfajohnson@gmail.com> - 2013-05-14 13:51 -0400
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-14 21:16 +0100
Re: Wish to try Linux "Chris F.A. Johnson" <cfajohnson@gmail.com> - 2013-05-14 17:49 -0400
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-15 00:02 +0100
Re: Wish to try Linux Robert Heller <heller@deepsoft.com> - 2013-05-09 15:03 -0500
Re: Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-05-23 14:09 +0100
Re: Wish to try Linux Richard Kettlewell <rjk@greenend.org.uk> - 2013-05-23 14:38 +0100
Re: Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-05-23 16:33 +0100
Re: Wish to try Linux John Hasler <jhasler@newsguy.com> - 2013-05-23 10:55 -0500
Re: Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-05-23 19:00 +0100
Re: Wish to try Linux Aragorn <thorongil@telenet.be.invalid> - 2013-06-01 11:43 +0200
Re: Wish to try Linux notbob <notbob@nothome.com> - 2013-06-01 11:37 +0000
Re: Wish to try Linux Balwinder S Dheeman <bsd.SANSPAM@anu.homelinux.net> - 2013-06-01 21:59 +0530
Re: Wish to try Linux Aragorn <thorongil@telenet.be.invalid> - 2013-06-01 19:14 +0200
Re: Wish to try Linux notbob <notbob@nothome.com> - 2013-06-01 17:43 +0000
Re: Wish to try Linux Michael Black <et472@ncf.ca> - 2013-06-01 19:33 -0400
Re: Wish to try Linux Aragorn <thorongil@telenet.be.invalid> - 2013-06-02 02:37 +0200
Re: Wish to try Linux Jean-David Beyer <jeandavid8@verizon.net> - 2013-06-01 23:05 -0400
Re: Wish to try Linux Richard Kettlewell <rjk@greenend.org.uk> - 2013-06-02 09:33 +0100
Re: Wish to try Linux Jean-David Beyer <jeandavid8@verizon.net> - 2013-06-02 07:02 -0400
Re: Wish to try Linux David Brown <david.brown@removethis.hesbynett.no> - 2013-06-02 13:26 +0200
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-06-02 15:47 +0100
Re: Wish to try Linux Jean-David Beyer <jeandavid8@verizon.net> - 2013-06-02 14:52 -0400
Re: Wish to try Linux David Brown <david.brown@removethis.hesbynett.no> - 2013-06-02 13:32 +0200
Re: Wish to try Linux Roger Blake <rogblake@iname.invalid> - 2013-05-23 17:09 +0000
Re: Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-05-23 19:06 +0100
Re: Wish to try Linux Robert Riches <spamtrap42@jacob21819.net> - 2013-05-24 04:48 +0000
Re: Wish to try Linux Bit Twister <BitTwister@mouse-potato.com> - 2013-05-09 20:03 +0000
Re: Wish to try Linux unruh <unruh@invalid.ca> - 2013-05-09 20:19 +0000
Re: Wish to try Linux bad sector <forgetski@postit_INVALID_.gov> - 2013-05-09 20:27 -0400
Re: Wish to try Linux unruh <unruh@invalid.ca> - 2013-05-10 15:30 +0000
Re: Wish to try Linux Stef <not@this.address.com> - 2013-05-10 03:05 +0000
Re: Wish to try Linux notbob <notbob@nothome.com> - 2013-05-10 14:35 +0000
Re: Wish to try Linux Stef <not@this.address.com> - 2013-05-10 16:44 +0000
Re: Wish to try Linux notbob <notbob@nothome.com> - 2013-05-10 16:57 +0000
Re: Wish to try Linux Stef <not@this.address.com> - 2013-05-11 03:59 +0000
Re: Wish to try Linux Michael Black <et472@ncf.ca> - 2013-05-11 00:27 -0400
Re: Wish to try Linux notbob <notbob@nothome.com> - 2013-05-11 12:49 +0000
Re: Wish to try Linux J G Miller <miller@yoyo.ORG> - 2013-05-11 12:56 +0000
Re: Wish to try Linux Aragorn <thorongil@telenet.be.invalid> - 2013-05-11 15:20 +0200
Re: Wish to try Linux notbob <notbob@nothome.com> - 2013-05-11 14:14 +0000
Re: Wish to try Linux Jean-David Beyer <jeandavid8@verizon.net> - 2013-05-11 10:30 -0400
Re: Wish to try Linux OOps Jean-David Beyer <jeandavid8@verizon.net> - 2013-05-11 10:38 -0400
Re: Wish to try Linux OOps Robert Riches <spamtrap42@jacob21819.net> - 2013-05-12 04:37 +0000
Re: Wish to try Linux Michael Black <et472@ncf.ca> - 2013-05-11 13:47 -0400
Re: Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-05-10 16:58 +0100
Re: Wish to try Linux Aragorn <stryder@telenet.be.invalid> - 2013-05-10 06:53 +0200
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-10 07:26 +0100
Re: Wish to try Linux Aragorn <stryder@telenet.be.invalid> - 2013-05-10 09:18 +0200
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-10 10:20 +0100
Re: Wish to try Linux Aragorn <stryder@telenet.be.invalid> - 2013-05-10 11:40 +0200
Re: Wish to try Linux Octothorpe <Octothorpe@invalid.com> - 2013-05-10 07:44 -0400
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-10 13:00 +0100
Re: Wish to try Linux Octothorpe <Octothorpe@invalid.com> - 2013-05-10 08:47 -0400
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-10 15:50 +0100
Re: Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-06-21 18:44 +0100
Re: Wish to try Linux Aragorn <thorongil@telenet.be.invalid> - 2013-06-21 19:53 +0200
Re: Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-06-21 18:55 +0100
Re: Wish to try Linux Aragorn <thorongil@telenet.be.invalid> - 2013-06-21 20:05 +0200
Re: Wish to try Linux Richard Kettlewell <rjk@greenend.org.uk> - 2013-06-21 19:17 +0100
Re: Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-06-21 19:56 +0100
Re: Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-06-21 19:59 +0100
Re: Wish to try Linux Antti Talsta <atalsta@gmail.com> - 2013-06-21 21:04 +0300
Re: Wish to try Linux Michael Black <et472@ncf.ca> - 2013-06-21 17:51 -0400
Re: Wish to try Linux Roger Blake <rogblake@iname.invalid> - 2013-06-22 01:48 +0000
Re: Wish to try Linux Stan Bischof <stan@worldbadminton.com> - 2013-06-24 16:48 +0000
Re: Wish to try Linux Stan Bischof <stan@worldbadminton.com> - 2013-06-24 16:56 +0000
Re: Wish to try Linux DenverD <DenverD@invalid.dk> - 2013-05-10 09:17 +0200
Re: Wish to try Linux lichtblitz <nospam@lichtblitz.invalid> - 2013-05-10 13:49 +0000
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-05-10 15:48 +0100
Re: Wish to try Linux Robert Heller <heller@deepsoft.com> - 2013-05-10 11:21 -0500
Re: Wish to try Linux lichtblitz <nospam@lichtblitz.invalid> - 2013-05-10 18:20 +0000
Re: Wish to try Linux Richard Kettlewell <rjk@greenend.org.uk> - 2013-05-10 19:54 +0100
Re: Wish to try Linux Jean-David Beyer <jeandavid8@verizon.net> - 2013-05-10 14:55 -0400
Re: Wish to try Linux Aragorn <stryder@telenet.be.invalid> - 2013-05-11 05:40 +0200
Re: Wish to try Linux Jean-David Beyer <jeandavid8@verizon.net> - 2013-05-11 07:55 -0400
Re: Wish to try Linux J G Miller <miller@yoyo.ORG> - 2013-05-10 16:07 +0000
Re: Wish to try Linux lichtblitz <nospam@lichtblitz.invalid> - 2013-05-10 18:29 +0000
Re: Wish to try Linux J G Miller <miller@yoyo.ORG> - 2013-05-10 19:48 +0000
Re: Wish to try Linux David Hough <noone$$@llondel.org> - 2013-05-10 18:13 +0100
Re: Wish to try Linux Dirk Weber <dma-weber@globe.lu> - 2013-05-10 19:09 +0200
Re: Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-05-14 19:01 +0100
Re: Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-06-23 22:55 +0100
Re: Wish to try Linux The Natural Philosopher <tnp@invalid.invalid> - 2013-06-24 00:34 +0100
Re: Wish to try Linux John Hasler <jhasler@newsguy.com> - 2013-06-23 19:23 -0500
Re: Wish to try Linux David Brown <david.brown@removethis.hesbynett.no> - 2013-06-25 18:50 +0200
Re: Wish to try Linux bruce.sinclair@NOSPAMORELSEagresearch.NOTco.NOTnz (Bruce Sinclair) - 2013-06-23 22:53 +0000
Re: Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-06-25 12:24 +0100
Re: Wish to try Linux Michael Black <et472@ncf.ca> - 2013-06-25 12:28 -0400
Re: Wish to try Linux bruce.sinclair@NOSPAMORELSEagresearch.NOTco.NOTnz (Bruce Sinclair) - 2013-06-25 23:11 +0000
Re: Wish to try Linux John Hasler <jhasler@newsguy.com> - 2013-06-23 19:30 -0500
Re: Wish to try Linux Ross Maloney <rmatycorp@iinet.net.au> - 2013-06-24 11:07 +0800
Re: Wish to try Linux Peter Percival <peterxpercival@hotmail.com> - 2013-06-25 12:52 +0100
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2013-05-23 14:38 +0100 |
| Message-ID | <87mwrlke9k.fsf@araminta.anjou.terraraq.org.uk> |
| In reply to | #8186 |
Peter Percival <peterxpercival@hotmail.com> writes: > Robert Heller wrote: >> and the Acer Aspire A5-4 notebook is *probably* 64-bit (am64). > > My output of my first Perl program tells me (irrelevant stuff snipped): > > PROCESSOR_ARCHITECTURE=AMD64 > PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 42 Stepping 7, GenuineIntel That is an i7-2600K. > PROCESSOR_LEVEL=6 > PROCESSOR_REVISION=2a07 > > I can't reconcile the mention of both AMD and Intel. AMD designed the 64-bit version of the architecture, hence ‘amd64’. Intel manufactured the particular implementation of it that you have. -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Peter Percival <peterxpercival@hotmail.com> |
|---|---|
| Date | 2013-05-23 16:33 +0100 |
| Message-ID | <knlcsg$4c2$1@news.albasani.net> |
| In reply to | #8187 |
Richard Kettlewell wrote: > Peter Percival <peterxpercival@hotmail.com> writes: >> Robert Heller wrote: > >>> and the Acer Aspire A5-4 notebook is *probably* 64-bit (am64). >> >> My output of my first Perl program tells me (irrelevant stuff snipped): >> >> PROCESSOR_ARCHITECTURE=AMD64 >> PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 42 Stepping 7, GenuineIntel > > That is an i7-2600K. > >> PROCESSOR_LEVEL=6 >> PROCESSOR_REVISION=2a07 >> >> I can't reconcile the mention of both AMD and Intel. > > AMD designed the 64-bit version of the architecture, hence ‘amd64’. > Intel manufactured the particular implementation of it that you have. Thank you for the explanation. I didn't know that AMD and Intel collaborated. -- I think I am an Elephant, Behind another Elephant Behind /another/ Elephant who isn't really there.... A.A. Milne
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2013-05-23 10:55 -0500 |
| Message-ID | <87fvxdadxl.fsf@thumper.dhh.gt.org> |
| In reply to | #8188 |
Peter Percival writes: > Thank you for the explanation. I didn't know that AMD and Intel > collaborated. They didn't. AMD established the standard and Intel followed it. -- John Hasler jhasler@newsguy.com Dancing Horse Hill Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | Peter Percival <peterxpercival@hotmail.com> |
|---|---|
| Date | 2013-05-23 19:00 +0100 |
| Message-ID | <knllgd$ndq$3@news.albasani.net> |
| In reply to | #8189 |
John Hasler wrote: > Peter Percival writes: >> Thank you for the explanation. I didn't know that AMD and Intel >> collaborated. > > They didn't. AMD established the standard and Intel followed it. Oh! I thought Intel were the leaders rather than the followers. Maybe that was in the 70s. -- I think I am an Elephant, Behind another Elephant Behind /another/ Elephant who isn't really there.... A.A. Milne
[toc] | [prev] | [next] | [standalone]
| From | Aragorn <thorongil@telenet.be.invalid> |
|---|---|
| Date | 2013-06-01 11:43 +0200 |
| Message-ID | <kocfg7$nlm$1@dont-email.me> |
| In reply to | #8191 |
On Thursday 23 May 2013 20:00, Peter Percival conveyed the following to comp.os.linux.misc... > John Hasler wrote: >> Peter Percival writes: >>> Thank you for the explanation. I didn't know that AMD and Intel >>> collaborated. >> >> They didn't. AMD established the standard and Intel followed it. > > Oh! I thought Intel were the leaders rather than the followers. > Maybe that was in the 70s. When Intel decided to develop a 64-bit processor - now known as the Itanium (IA64) architecture - they abandoned the x86 platform. Itanium had/has an x86 emulation mode, but this is very slow and only runs 32- and 16-bit bit code. AMD on the other hand chose to extend the x86 architecture to the 64-bit level, whereby 32-bit applications could be run alongside of 64-bit applications at native speed. With the Itanium being very expensive and AMD's x86-64 implementation being very interesting both technically and economically, Intel tried to make their own version of x86-64, but it wasn't fully functional and it wasn't compatible with the existing x86-64 software. They then subsequently chose to take out a license on the AMD64 patent, albeit that they keep referring to it by the "Intel 64" moniker. Some companies - Sun Microsystems (now Oracle) and Microsoft - refer to AMD64 as "x64", but this is not an official name for the platform. The official designations are "AMD64" and "x86-64". -- = Aragorn = GNU/Linux user #223157 - http://www.linuxcounter.net
[toc] | [prev] | [next] | [standalone]
| From | notbob <notbob@nothome.com> |
|---|---|
| Date | 2013-06-01 11:37 +0000 |
| Message-ID | <slrnkqjn64.2u2.notbob@nbleet.hcc.net> |
| In reply to | #8277 |
On 2013-06-01, Aragorn <thorongil@telenet.be.invalid> wrote: > and 16-bit bit code. AMD on the other hand chose to extend the x86 > architecture to the 64-bit level, whereby 32-bit applications could be > run alongside of 64-bit applications at native speed. Hmmm..... very interesting. Thanks for that synopsis, Aragorn. Being a end-of-life haredware fan, I'll probably move up to an AMD64 platform and 64 bit computing in the not-to-distant future. Reading wiki on the subject, I was disappointed to learn Slack is an either-or distro. Is that why alienbob has spent so much time on dual libs? I'd hate to think I'd hafta abandon Slack for Arch or Debian, though I'm confident my yrs with Slack will serve me well, should I change. nb
[toc] | [prev] | [next] | [standalone]
| From | Balwinder S Dheeman <bsd.SANSPAM@anu.homelinux.net> |
|---|---|
| Date | 2013-06-01 21:59 +0530 |
| Message-ID | <q3kp7ax4ll.ln2@news.homelinux.net> |
| In reply to | #8278 |
On 06/01/2013 05:07 PM, notbob wrote: > On 2013-06-01, Aragorn <thorongil@telenet.be.invalid> wrote: > >> and 16-bit bit code. AMD on the other hand chose to extend the x86 >> architecture to the 64-bit level, whereby 32-bit applications could be >> run alongside of 64-bit applications at native speed. > > Hmmm..... very interesting. Thanks for that synopsis, Aragorn. Being > a end-of-life haredware fan, I'll probably move up to an AMD64 > platform and 64 bit > computing in the not-to-distant future. Reading wiki on the subject, > I was disappointed to learn Slack is an either-or distro. Is that why > alienbob has spent so much time on dual libs? I'd hate to think I'd > hafta abandon Slack for Arch or Debian, though I'm confident my yrs > with Slack will serve me well, should I change. Yes, of course; trying other distributions would definitely be an addition your experience with Linux. Moreover, you already know that there also exist better distributions to Slack :P I for one, OTOH, am not distracting you from Slackware ;) -- Balwinder S 'bdheeman' Dheeman (http://werc.homelinux.net/contact/) "GNU/Linux, developed by volunteers, is much better, but it's not the best as yet. Do you too work on making a difference?"
[toc] | [prev] | [next] | [standalone]
| From | Aragorn <thorongil@telenet.be.invalid> |
|---|---|
| Date | 2013-06-01 19:14 +0200 |
| Message-ID | <kod9tf$2a6$1@dont-email.me> |
| In reply to | #8278 |
On Saturday 01 June 2013 13:37, notbob conveyed the following to comp.os.linux.misc... > On 2013-06-01, Aragorn <thorongil@telenet.be.invalid> wrote: > >> and 16-bit bit code. AMD on the other hand chose to extend the x86 >> architecture to the 64-bit level, whereby 32-bit applications could >> be run alongside of 64-bit applications at native speed. > > Hmmm..... very interesting. Thanks for that synopsis, Aragorn. Being > a end-of-life haredware fan, I'll probably move up to an AMD64 > platform and 64 bit computing in the not-to-distant future. Reading > wiki on the subject, I was disappointed to learn Slack is an either-or > distro. Is that why alienbob has spent so much time on dual libs? Well, yes, but truth be told, these days not too much software comes as 32-bit-only anymore. The biggest problem in the past used to be to get the proprietary plugin vendors - <cough> Adobe et al <cough> - to support 64-bit GNU/Linux, but that's all behind us now. My Mageia 1 system here is a so-called multi-lib system, so it's an x86-64 distribution with 32-bit compatibility support via the kernel and shared libraries, but in all honesty, I don't think I have any actual 32-bit packages installed here, other than that compatibility layer. Everything I actively run on this machine is 64-bit. > I'd hate to think I'd hafta abandon Slack for Arch or Debian, though > I'm confident my yrs with Slack will serve me well, should I change. They would, but you won't have to abandon Slackware at all. Like I said, you can essentially get almost all x86 software in a 64-bit form these days. I would also like to add that a new, third ABI is on its way in, albeit that only a few distributions - e.g. Gentoo - are supporting it right now. It's officially called "x32", but it is a 64-bit system with a mostly 32-bit userland, so as to be able to use the smaller pointer sizes et al of 32-bit. It is potentially interesting for 64-bit capable but low-spec machines which have only little RAM. -- = Aragorn = GNU/Linux user #223157 - http://www.linuxcounter.net
[toc] | [prev] | [next] | [standalone]
| From | notbob <notbob@nothome.com> |
|---|---|
| Date | 2013-06-01 17:43 +0000 |
| Message-ID | <slrnkqkclc.2u2.notbob@nbleet.hcc.net> |
| In reply to | #8280 |
On 2013-06-01, Aragorn <thorongil@telenet.be.invalid> wrote: > Well, yes, but truth be told, these days not too much software comes as > 32-bit-only anymore. I'm 13.37 and ALL 32-bit and run a lotta non-std graphics pkgs. Only had one prob not being 64-bit and that was for some arduino compiler pkg. A Slacky packager bailed me out. Still, "the end" is now viewable on the horiz. ;) nb
[toc] | [prev] | [next] | [standalone]
| From | Michael Black <et472@ncf.ca> |
|---|---|
| Date | 2013-06-01 19:33 -0400 |
| Message-ID | <alpine.LNX.2.02.1306011900280.23617@darkstar.example.org> |
| In reply to | #8278 |
On Sat, 1 Jun 2013, notbob wrote: > On 2013-06-01, Aragorn <thorongil@telenet.be.invalid> wrote: > >> and 16-bit bit code. AMD on the other hand chose to extend the x86 >> architecture to the 64-bit level, whereby 32-bit applications could be >> run alongside of 64-bit applications at native speed. > > Hmmm..... very interesting. Thanks for that synopsis, Aragorn. Being > a end-of-life haredware fan, I'll probably move up to an AMD64 > platform and 64 bit > computing in the not-to-distant future. Reading wiki on the subject, > I was disappointed to learn Slack is an either-or distro. Is that why > alienbob has spent so much time on dual libs? I'd hate to think I'd > hafta abandon Slack for Arch or Debian, though I'm confident my yrs > with Slack will serve me well, should I change. > I just found an Xbox 350 last night, coming home. I haven't plugged it in, but my general experience is that a lot of discard works fine. I check when I get home, it runs Linux. I look at the specs, it's a PowerPC CPU, but triple core, running at just over 3GHz if I read it right. It's even 64bits, I've not gotten to that point yet. And likely good graphics. It even uses SATA drives, so I can use one of the ones I found in the garbage, so long as I make an adapter. So I start fantasizing, and then realize the thing only as 512megs of RAM, and I have moved beyond that. Worse, since it's a game console, there's no easy way to add ram. So much for the fantasy. I figure if it works, I may find someone with an "old" computer that's better than what I have to trade. Vut I did score a $10 GPS unit that is actually portable, at the Rotary Club garage sale this morning. It seems to work fine, even the Ion-Lithium battery holds a charge. Michael
[toc] | [prev] | [next] | [standalone]
| From | Aragorn <thorongil@telenet.be.invalid> |
|---|---|
| Date | 2013-06-02 02:37 +0200 |
| Message-ID | <koe3sq$728$1@dont-email.me> |
| In reply to | #8282 |
On Sunday 02 June 2013 01:33, Michael Black conveyed the following to comp.os.linux.misc... > I just found an Xbox 350 last night, coming home. I haven't plugged > it in, but my general experience is that a lot of discard works fine. > I check when I get home, it runs Linux. I look at the specs, it's a > PowerPC CPU, but triple core, running at just over 3GHz if I read it > right. It's even 64bits, I've not gotten to that point yet. And > likely good graphics. It even uses SATA drives, so I can use one of > the ones I found in the garbage, so long as I make an adapter. > > So I start fantasizing, and then realize the thing only as 512megs of > RAM, and I have moved beyond that. Worse, since it's a game console, > there's no easy way to add ram. Be advised though that the PowerPC architecture is a RISC platform, so the binary code for that platform will be more compact than code compiled for x86(-64). RISC code is made up of micro-ops and is therefore highly optimized for both efficiency and memory consumption. Ergo, that machine's RAM requirements won't be as strict as for x86 - there's more headroom - albeit that 512 MiB is indeed a bit on the meager side. -- = Aragorn = GNU/Linux user #223157 - http://www.linuxcounter.net
[toc] | [prev] | [next] | [standalone]
| From | Jean-David Beyer <jeandavid8@verizon.net> |
|---|---|
| Date | 2013-06-01 23:05 -0400 |
| Message-ID | <koecp302o35@news6.newsguy.com> |
| In reply to | #8283 |
On 06/01/2013 08:37 PM, Aragorn wrote: > Be advised though that the PowerPC architecture is a RISC platform, so > the binary code for that platform will be more compact than code > compiled for x86(-64). RISC code is made up of micro-ops and is > therefore highly optimized for both efficiency and memory consumption. > > Ergo, that machine's RAM requirements won't be as strict as for x86 - > there's more headroom - albeit that 512 MiB is indeed a bit on the > meager side. In the distant past, a colleague and I had occasion to write an assembly-language level optimizer (mainly for C programs) for the SPARC RISC processor. We had already done one for the AT&T 32100 series processors (conventional architecture). I found doing that to be somewhat more difficult than for the normal processors such as Intel 80386 and the Motorola 68000 series of the same time. Delay slots, etc. But I did not find that they used any less memory for the instructions because any one instruction may have been smaller than for complex instruction set machines, but it took between 2 or 3 instructions to do the same thing as a single instruction on the more traditional machines. Furthermore, you then had to do 2 to 3 instruction fetches, so they tended to run slower per computation even though any single instruction could run faster. I do like the idea of a RISC processor, and you might say that the SPARC was not really very "reduced" anyway.
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2013-06-02 09:33 +0100 |
| Message-ID | <87sj1029pk.fsf@araminta.anjou.terraraq.org.uk> |
| In reply to | #8284 |
Jean-David Beyer <jeandavid8@verizon.net> writes: > In the distant past, a colleague and I had occasion to write an > assembly-language level optimizer (mainly for C programs) for the SPARC > RISC processor. We had already done one for the AT&T 32100 series > processors (conventional architecture). I found doing that to be > somewhat more difficult than for the normal processors such as Intel > 80386 and the Motorola 68000 series of the same time. Delay slots, etc. > > But I did not find that they used any less memory for the instructions > because any one instruction may have been smaller than for complex > instruction set machines, but it took between 2 or 3 instructions to > do the same thing as a single instruction on the more traditional > machines. Furthermore, you then had to do 2 to 3 instruction fetches, > so they tended to run slower per computation even though any single > instruction could run faster. Comparing a few libraries which we build across multiple platforms, I find SPARC produces object code up to 1-50% bigger than x86, but x86 20-30% bigger than PPC. My conclusion is that you can’t reliably say RISC ISAs produce either larger or smaller code than CISC, and aren’t on particularly solid ground seeking a comparison just between two specific ISAs - i.e. it can vary a fair bit depending on the specific code. (Stripped object code in all cases, mostly compiled C.) -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Jean-David Beyer <jeandavid8@verizon.net> |
|---|---|
| Date | 2013-06-02 07:02 -0400 |
| Message-ID | <kof8n802dnc@news7.newsguy.com> |
| In reply to | #8285 |
On 06/02/2013 04:33 AM, Richard Kettlewell wrote: > Jean-David Beyer <jeandavid8@verizon.net> writes: >> In the distant past, a colleague and I had occasion to write an >> assembly-language level optimizer (mainly for C programs) for the SPARC >> RISC processor. We had already done one for the AT&T 32100 series >> processors (conventional architecture). I found doing that to be >> somewhat more difficult than for the normal processors such as Intel >> 80386 and the Motorola 68000 series of the same time. Delay slots, etc. >> >> But I did not find that they used any less memory for the instructions >> because any one instruction may have been smaller than for complex >> instruction set machines, but it took between 2 or 3 instructions to >> do the same thing as a single instruction on the more traditional >> machines. Furthermore, you then had to do 2 to 3 instruction fetches, >> so they tended to run slower per computation even though any single >> instruction could run faster. > > Comparing a few libraries which we build across multiple platforms, I > find SPARC produces object code up to 1-50% bigger than x86, but x86 > 20-30% bigger than PPC. My conclusion is that you can’t reliably say > RISC ISAs produce either larger or smaller code than CISC, and aren’t on > particularly solid ground seeking a comparison just between two specific > ISAs - i.e. it can vary a fair bit depending on the specific code. > > (Stripped object code in all cases, mostly compiled C.) > My guess is that you are right. Where I worked, they also were trying to build a processor RISC chip oriented specifically to running compiled C programs. I do not know if they ever manufactured the chip or not, but I did get a copy of the instruction set. I do not know what they were anymore, but I do remember that this so-called RISC processor, that they were calling CRISP at the time, had more op-codes than any other machine I had ever seen, even the IBM 7094, Something like 350 op-codes. I was disgusted. If that is C REDUCED INSTRUCTION SET PROCESSOR, I do not know what they thought would be a complex instruction set machine. I know I never got asked to write an optimizer for it. That company, that once was a pioneer in computers, had completely lost it, technically, by the time they were allowed to make computers again. They had designed a pretty good 32-bit processor when people were trying to make do with a PDP-11 computer or an 8086 Intel chip. We did the optimizer for it. They had a bunch of benchmarks that we were to optimize for, and they were very stupid. We could easily get 10:1 speed ups on then. They even had a C version of the so-called Whetstone benchmark. But their version had some errors in it. Our optimizer made that go so fast it was difficult to time it. There was one loop in there that added or multiplied a bunch of floating point numbers and did it 10,000 times (or something like that). I had put a loop invariant code motion optimization in there, and it moved all the calculations outside the loop for a fantastic speed-up. My colleague had live-dead analysis and noticed that the empty loop had nothing in it, and that the loop variable was not used later, so he removed those instructions. He also removed the instructions I had moved out of the loop, since their values were never used. That happened to most of the code in that so-called benchmark. We later did a study of the programs actually used by the UNIX machines in our computation center. We found out what the most-used programs were and made benchmarks from them. The troff (text processor) program was the winner and we made a benchmark from it. But marketing would not let us use it because it got only 1% (or something like that) improvement. Programming style at that company was terrible from an optimization standpoint. The programmers, who were mostly researchers and never wrote for production, were terrible. They loved to make all variables external (in C), to save the bother of passing arguments to functions. But optimizing code with external variables was almost impossible because those variables could appear in other files that the optimizer could not see, so we had no way of knowing if code in another file could change their values unseen to us, so we could not optimize them. But some genius in marketing said there was a multiply of a floating point number by two, and they designed a multiply by 2 floating point op-code for it (that added 1 to the exponent). I told them not to do it because we would never generate the instruction because that "2" was an external variable and it could change, unseen by the program, if an interrupt came along. So they put it in anyway and we never generated it. I said that they would have been wiser to use the chip area to increase the size of the instruction cache (from 2 instructions to some more), but they did not do it. They were in love with useless complexity.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@removethis.hesbynett.no> |
|---|---|
| Date | 2013-06-02 13:26 +0200 |
| Message-ID | <_LWdnTPUWuFMtjbMnZ2dnUVZ8vydnZ2d@lyse.net> |
| In reply to | #8286 |
On 02/06/13 13:02, Jean-David Beyer wrote: > On 06/02/2013 04:33 AM, Richard Kettlewell wrote: >> Jean-David Beyer <jeandavid8@verizon.net> writes: >>> In the distant past, a colleague and I had occasion to write an >>> assembly-language level optimizer (mainly for C programs) for the SPARC >>> RISC processor. We had already done one for the AT&T 32100 series >>> processors (conventional architecture). I found doing that to be >>> somewhat more difficult than for the normal processors such as Intel >>> 80386 and the Motorola 68000 series of the same time. Delay slots, etc. >>> >>> But I did not find that they used any less memory for the instructions >>> because any one instruction may have been smaller than for complex >>> instruction set machines, but it took between 2 or 3 instructions to >>> do the same thing as a single instruction on the more traditional >>> machines. Furthermore, you then had to do 2 to 3 instruction fetches, >>> so they tended to run slower per computation even though any single >>> instruction could run faster. >> >> Comparing a few libraries which we build across multiple platforms, I >> find SPARC produces object code up to 1-50% bigger than x86, but x86 >> 20-30% bigger than PPC. My conclusion is that you can’t reliably say >> RISC ISAs produce either larger or smaller code than CISC, and aren’t on >> particularly solid ground seeking a comparison just between two specific >> ISAs - i.e. it can vary a fair bit depending on the specific code. >> >> (Stripped object code in all cases, mostly compiled C.) >> > My guess is that you are right. Where I worked, they also were trying to > build a processor RISC chip oriented specifically to running compiled C > programs. I do not know if they ever manufactured the chip or not, but I > did get a copy of the instruction set. I do not know what they were > anymore, but I do remember that this so-called RISC processor, that they > were calling CRISP at the time, had more op-codes than any other machine > I had ever seen, even the IBM 7094, Something like 350 op-codes. I was > disgusted. If that is C REDUCED INSTRUCTION SET PROCESSOR, I do not know > what they thought would be a complex instruction set machine. I know I > never got asked to write an optimizer for it. > It is a common misconception that a RISC architecture has a small number of opcodes - i.e., the parsing is "Reduced" "Instruction-Set" "Computer". In fact, RISC means the /instructions/ are reduced, not the /instruction set/ - it is "Reduced Instruction" "Set" "Computer". Thus a RISC architecture like the PPC has a very large number of op-codes, but they are almost all "simple" and execute in a single cycle rather than with loops, microcode, multiple steps, etc., as is normal in CISC architectures. Some instructions, like the bitfield manipulations, are pretty complicated - but as they execute using dedicated single-cycle logic, they are still classed as "simple". Of course, there are still some multi-cycle complex instructions, especially for things like floating-point operations. But most of the op-codes are "simple".
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2013-06-02 15:47 +0100 |
| Message-ID | <kofluj$mfc$1@news.albasani.net> |
| In reply to | #8288 |
On 02/06/13 12:26, David Brown wrote: > On 02/06/13 13:02, Jean-David Beyer wrote: >> On 06/02/2013 04:33 AM, Richard Kettlewell wrote: >>> Jean-David Beyer <jeandavid8@verizon.net> writes: >>>> In the distant past, a colleague and I had occasion to write an >>>> assembly-language level optimizer (mainly for C programs) for the >>>> SPARC >>>> RISC processor. We had already done one for the AT&T 32100 series >>>> processors (conventional architecture). I found doing that to be >>>> somewhat more difficult than for the normal processors such as Intel >>>> 80386 and the Motorola 68000 series of the same time. Delay slots, >>>> etc. >>>> >>>> But I did not find that they used any less memory for the instructions >>>> because any one instruction may have been smaller than for complex >>>> instruction set machines, but it took between 2 or 3 instructions to >>>> do the same thing as a single instruction on the more traditional >>>> machines. Furthermore, you then had to do 2 to 3 instruction fetches, >>>> so they tended to run slower per computation even though any single >>>> instruction could run faster. >>> >>> Comparing a few libraries which we build across multiple platforms, I >>> find SPARC produces object code up to 1-50% bigger than x86, but x86 >>> 20-30% bigger than PPC. My conclusion is that you can’t reliably say >>> RISC ISAs produce either larger or smaller code than CISC, and >>> aren’t on >>> particularly solid ground seeking a comparison just between two >>> specific >>> ISAs - i.e. it can vary a fair bit depending on the specific code. >>> >>> (Stripped object code in all cases, mostly compiled C.) >>> >> My guess is that you are right. Where I worked, they also were trying to >> build a processor RISC chip oriented specifically to running compiled C >> programs. I do not know if they ever manufactured the chip or not, but I >> did get a copy of the instruction set. I do not know what they were >> anymore, but I do remember that this so-called RISC processor, that they >> were calling CRISP at the time, had more op-codes than any other machine >> I had ever seen, even the IBM 7094, Something like 350 op-codes. I was >> disgusted. If that is C REDUCED INSTRUCTION SET PROCESSOR, I do not know >> what they thought would be a complex instruction set machine. I know I >> never got asked to write an optimizer for it. >> > > It is a common misconception that a RISC architecture has a small > number of opcodes - i.e., the parsing is "Reduced" "Instruction-Set" > "Computer". In fact, RISC means the /instructions/ are reduced, not > the /instruction set/ - it is "Reduced Instruction" "Set" "Computer". > > Thus a RISC architecture like the PPC has a very large number of > op-codes, but they are almost all "simple" and execute in a single > cycle rather than with loops, microcode, multiple steps, etc., as is > normal in CISC architectures. Some instructions, like the bitfield > manipulations, are pretty complicated - but as they execute using > dedicated single-cycle logic, they are still classed as "simple". Of > course, there are still some multi-cycle complex instructions, > especially for things like floating-point operations. But most of the > op-codes are "simple". > And of course as anyone who has run FORTH will tell you, you can trade compactness of code for execution speed, more or less at will. Its possible also to hunt through assembler code and find any pattern of more than half a dozen instructions, turn it into a subroutine and call it.. destroys pipelines of course. -- Ineptocracy (in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.
[toc] | [prev] | [next] | [standalone]
| From | Jean-David Beyer <jeandavid8@verizon.net> |
|---|---|
| Date | 2013-06-02 14:52 -0400 |
| Message-ID | <kog4a60757@news4.newsguy.com> |
| In reply to | #8293 |
On 06/02/2013 10:47 AM, The Natural Philosopher wrote: > On 02/06/13 12:26, David Brown wrote: >> On 02/06/13 13:02, Jean-David Beyer wrote: >>> On 06/02/2013 04:33 AM, Richard Kettlewell wrote: >>>> Jean-David Beyer <jeandavid8@verizon.net> writes: >>>>> In the distant past, a colleague and I had occasion to write an >>>>> assembly-language level optimizer (mainly for C programs) for the >>>>> SPARC >>>>> RISC processor. We had already done one for the AT&T 32100 series >>>>> processors (conventional architecture). I found doing that to be >>>>> somewhat more difficult than for the normal processors such as Intel >>>>> 80386 and the Motorola 68000 series of the same time. Delay slots, >>>>> etc. >>>>> >>>>> But I did not find that they used any less memory for the >>>>> instructions >>>>> because any one instruction may have been smaller than for complex >>>>> instruction set machines, but it took between 2 or 3 instructions to >>>>> do the same thing as a single instruction on the more traditional >>>>> machines. Furthermore, you then had to do 2 to 3 instruction >>>>> fetches, >>>>> so they tended to run slower per computation even though any single >>>>> instruction could run faster. >>>> >>>> Comparing a few libraries which we build across multiple platforms, I >>>> find SPARC produces object code up to 1-50% bigger than x86, but x86 >>>> 20-30% bigger than PPC. My conclusion is that you can’t reliably say >>>> RISC ISAs produce either larger or smaller code than CISC, and >>>> aren’t on >>>> particularly solid ground seeking a comparison just between two >>>> specific >>>> ISAs - i.e. it can vary a fair bit depending on the specific code. >>>> >>>> (Stripped object code in all cases, mostly compiled C.) >>>> >>> My guess is that you are right. Where I worked, they also were >>> trying to >>> build a processor RISC chip oriented specifically to running compiled C >>> programs. I do not know if they ever manufactured the chip or not, >>> but I >>> did get a copy of the instruction set. I do not know what they were >>> anymore, but I do remember that this so-called RISC processor, that >>> they >>> were calling CRISP at the time, had more op-codes than any other >>> machine >>> I had ever seen, even the IBM 7094, Something like 350 op-codes. I was >>> disgusted. If that is C REDUCED INSTRUCTION SET PROCESSOR, I do not >>> know >>> what they thought would be a complex instruction set machine. I know I >>> never got asked to write an optimizer for it. >>> >> >> It is a common misconception that a RISC architecture has a small >> number of opcodes - i.e., the parsing is "Reduced" "Instruction-Set" >> "Computer". In fact, RISC means the /instructions/ are reduced, not >> the /instruction set/ - it is "Reduced Instruction" "Set" "Computer". >> >> Thus a RISC architecture like the PPC has a very large number of >> op-codes, but they are almost all "simple" and execute in a single >> cycle rather than with loops, microcode, multiple steps, etc., as is >> normal in CISC architectures. Some instructions, like the bitfield >> manipulations, are pretty complicated - but as they execute using >> dedicated single-cycle logic, they are still classed as "simple". Of >> course, there are still some multi-cycle complex instructions, >> especially for things like floating-point operations. But most of >> the op-codes are "simple". >> > And of course as anyone who has run FORTH will tell you, you can trade > compactness of code for execution speed, more or less at will. Its > possible also to hunt through assembler code and find any pattern of > more than half a dozen instructions, turn it into a subroutine and > call it.. destroys pipelines of course. > Destroys pipelines, but can improve working set locality. It is a tradeoff of course. The optimizer I helped write had an "optimize for speed" and an "optimize for space" option. In optimize for speed, it would expand subroutines in-line (and it had to be careful about recursive subroutines in many manifestations). But a secondary benefit for expanding a subroutine inline is that it gave the optimizer the opportunity to make much more extensive optimizations because it had more information available. I found writing optimizers a lot of fun, but realistically, since it could easily take 18 months to make significant changes in an optimizer, and test the functions, test the entire optimizer, the entire compilation system, then build the UNIX kernel with all the optimizations turned on and get it to keep working, and then send it to system integration and system test, .... Well in that amount of time, the speed of the processors doubled, and we rarely got a 100% speed increase with optimizations except for the benchmarks, so it was kind-of futile. In a reasonable world, the optimizer would continue to work for the faster processor, but they always made other little changes in the processors so the optimzations would not work, and we had to do big parts over again. Lots of fun for problem solving, but I somehow doubt the computing world was actually improved much by our work. Sigh!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@removethis.hesbynett.no> |
|---|---|
| Date | 2013-06-02 13:32 +0200 |
| Message-ID | <_qmdnfJ9arjPsDbMnZ2dnUVZ7t-dnZ2d@lyse.net> |
| In reply to | #8283 |
On 02/06/13 02:37, Aragorn wrote: > On Sunday 02 June 2013 01:33, Michael Black conveyed the following to > comp.os.linux.misc... > >> I just found an Xbox 350 last night, coming home. I haven't plugged >> it in, but my general experience is that a lot of discard works fine. >> I check when I get home, it runs Linux. I look at the specs, it's a >> PowerPC CPU, but triple core, running at just over 3GHz if I read it >> right. It's even 64bits, I've not gotten to that point yet. And >> likely good graphics. It even uses SATA drives, so I can use one of >> the ones I found in the garbage, so long as I make an adapter. >> >> So I start fantasizing, and then realize the thing only as 512megs of >> RAM, and I have moved beyond that. Worse, since it's a game console, >> there's no easy way to add ram. > > Be advised though that the PowerPC architecture is a RISC platform, so > the binary code for that platform will be more compact than code > compiled for x86(-64). RISC code is made up of micro-ops and is > therefore highly optimized for both efficiency and memory consumption. > > Ergo, that machine's RAM requirements won't be as strict as for x86 - > there's more headroom - albeit that 512 MiB is indeed a bit on the > meager side. > Figures vary a bit according to the type of code and the exact hardware, but it is usual for RISC architectures to need larger programs than CISC architectures. The x86 is unusually inefficient compared to other CISC ISA's like m68k, because of its absurd numbers of instruction prefixes. x86-64 is better here, as the prefixes are a bit more rational. But in general, RISC instructions are simpler and do less than CISC instructions, and they also have specific fixed sizes. So while a CISC machine might handle "x = a[i++]" in a single opcode of perhaps 2 bytes, a RISC machine might need two opcodes at 32-bytes each. Additionally, RISC architectures often need a little more data ram, as they are often quite inefficient at accessing data less than 32-bit (or whatever their natural width is). So smaller data is often aligned as 32-bit, while on a CISC architecture it could be more tightly packed. I doubt if the difference is particularly noticeable in real-world code, however.
[toc] | [prev] | [next] | [standalone]
| From | Roger Blake <rogblake@iname.invalid> |
|---|---|
| Date | 2013-05-23 17:09 +0000 |
| Message-ID | <20130523131257@news.eternal-september.org> |
| In reply to | #8188 |
On 2013-05-23, Peter Percival <peterxpercival@hotmail.com> wrote: > Thank you for the explanation. I didn't know that AMD and Intel > collaborated. It's more like Intel's own 64-bit implementation (Itanium) took a nosedive in the marketplace largely due to its lack of native support for legacy 32-bit code. The following paper, "A History of Modern 64-bit Computing" may be of interest: http://www.cs.washington.edu/education/courses/csep590/06au/projects/history-64-bit.pdf -- ----------------------------------------------------------------------------- Roger Blake (Change "invalid" to "com" for email. Google Groups killfiled.) -----------------------------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Peter Percival <peterxpercival@hotmail.com> |
|---|---|
| Date | 2013-05-23 19:06 +0100 |
| Message-ID | <knllqf$p4q$1@news.albasani.net> |
| In reply to | #8190 |
Roger Blake wrote: > On 2013-05-23, Peter Percival <peterxpercival@hotmail.com> wrote: >> Thank you for the explanation. I didn't know that AMD and Intel >> collaborated. > > It's more like Intel's own 64-bit implementation (Itanium) took a nosedive > in the marketplace largely due to its lack of native support for legacy > 32-bit code. > > The following paper, "A History of Modern 64-bit Computing" may be of interest: > > http://www.cs.washington.edu/education/courses/csep590/06au/projects/history-64-bit.pdf Thank you, I'll read it later. -- I think I am an Elephant, Behind another Elephant Behind /another/ Elephant who isn't really there.... A.A. Milne
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web