| Tahoe and Alpha Architectures [message #366725] |
Tue, 24 April 2018 15:43  |
Charles Richmond
Messages: 2754
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
The Tahoe architecture and the DEC Alpha architecture both are much
nicer on the assembly level than the x86 architecture. Not many here
would disagree with that. Why does Intel *not* produce modern versions
of those architectures and PC makers use those???
Most of modern software can be re-compiled for the new instruction sets.
Tell me why Intel should *not* adopt these architectures; not really why
Intel does not...
--
numerist at aquaporin4 dot com
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366730 is a reply to message #366725] |
Tue, 24 April 2018 15:52  |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2018-04-24, Charles Richmond <numerist@aquaporin4.com> wrote:
> The Tahoe architecture and the DEC Alpha architecture both are much
> nicer on the assembly level than the x86 architecture. Not many here
> would disagree with that. Why does Intel *not* produce modern versions
> of those architectures and PC makers use those???
>
> Most of modern software can be re-compiled for the new instruction sets.
>
> Tell me why Intel should *not* adopt these architectures; not really why
> Intel does not...
I suspect that the answer begins with a dollar sign.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ Fight low-contrast text in web pages! http://contrastrebellion.com
|
|
|
|
| Tahoe and Alpha Architectures [message #366732 is a reply to message #366725] |
Tue, 24 April 2018 16:13 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
If some PC maker used a different architecture chip for its new
computer, then I would have to buy new copies of software for it.
Software is not usually sold as source code. That would be too easy to pirate.
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366752 is a reply to message #366730] |
Tue, 24 April 2018 21:53 |
|
|
Originally posted by: J. Clarke
On 24 Apr 2018 19:52:13 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
wrote:
> On 2018-04-24, Charles Richmond <numerist@aquaporin4.com> wrote:
>
>> The Tahoe architecture and the DEC Alpha architecture both are much
>> nicer on the assembly level than the x86 architecture. Not many here
>> would disagree with that. Why does Intel *not* produce modern versions
>> of those architectures and PC makers use those???
>>
>> Most of modern software can be re-compiled for the new instruction sets.
>>
>> Tell me why Intel should *not* adopt these architectures; not really why
>> Intel does not...
>
> I suspect that the answer begins with a dollar sign.
It does but not the way you mean. Windows NT runs on Alpha, i860,
MIPS R4000, PowerPC, Itanium, and SPARC. None of them except x86
developed enough sales to pay for continued development. So the
dollar sign is in the cost of continuing to develop for a dead
platform.
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366757 is a reply to message #366752] |
Tue, 24 April 2018 23:27 |
|
|
Originally posted by: Grant Taylor
On 04/24/2018 07:53 PM, J. Clarke wrote:
> It does but not the way you mean. Windows NT runs on Alpha, i860,
> MIPS R4000, PowerPC, Itanium, and SPARC.
Windows NT is from Microsoft, not Intel.
You also missed x86 and x86_64 (or x64 if you prefer).
Note: Intel makes three of those architectures: x86 (x64), i860
(i960), and Itanium.
--
Grant. . . .
unix || die
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366758 is a reply to message #366732] |
Tue, 24 April 2018 23:30 |
|
|
Originally posted by: Grant Taylor
On 04/24/2018 02:13 PM, Quadibloc wrote:
> If some PC maker used a different architecture chip for its new computer,
> then I would have to buy new copies of software for it. Software is
> not usually sold as source code. That would be too easy to pirate.
DEC released FX!32 to run x86 (Win32) programs on Windows NT on alpha.
Windows NT 4.x shipped with binaries for multiple architectures on the
same CD-ROM and used the same CD-KEY.
--
Grant. . . .
unix || die
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366759 is a reply to message #366757] |
Tue, 24 April 2018 23:33 |
|
|
Originally posted by: J. Clarke
On Tue, 24 Apr 2018 21:27:28 -0600, Grant Taylor
<gtaylor@tnetconsulting.net> wrote:
> On 04/24/2018 07:53 PM, J. Clarke wrote:
>> It does but not the way you mean. Windows NT runs on Alpha, i860,
>> MIPS R4000, PowerPC, Itanium, and SPARC.
>
> Windows NT is from Microsoft, not Intel.
>
> You also missed x86 and x86_64 (or x64 if you prefer).
They are assumed.
> Note: Intel makes three of those architectures: x86 (x64), i860
> (i960), and Itanium.
And of those the only one that sells is x86. So come up with a
convincing argument that some other architecture will actually sell
enough units to be worth the cost of development.
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366760 is a reply to message #366725] |
Tue, 24 April 2018 23:43 |
|
|
Originally posted by: Grant Taylor
On 04/24/2018 01:43 PM, Charles Richmond wrote:
> The Tahoe architecture and the DEC Alpha architecture both are much
> nicer on the assembly level than the x86 architecture. Not many here
> would disagree with that. Why does Intel *not* produce modern versions
> of those architectures and PC makers use those???
I'm not familiar with Tahoe and can't comment.
Alpha was developed by DEC, purchased by Compaq and subsequently HP.
Thus HP owns the Intellectual Property of the Alpha CPUs. — At least
the portion that did not get sold off to other companies. — I would be
somewhat surprised if there aren't pieces of Alpha architecture deep in
the bowels of other CPU architectures.
I'm not a programmer myself, much less an assembly programmer, so I
can't say with confidence. But it is my understanding that the PDP /
VAX were meant to be nice to the assembly programmers. x86, not so much so.
IMHO, x86 is the Ethernet of CPU architectures, cheap, easy, (made to
be) fast, prolific. None of those things mean that they are superior.
(Speed is debatable.)
Intel does not own the Intellectual Property nor are they likely to
license it.
Also, what would a modern version of the aforementioned CPUs be. I
suspect the x86 architecture is quite a bit different now compared to
what it was in the mid '90s.
All of the systems I ever saw that used the other architectures were at
least one order of magnitude more expensive than the x86 machine, if not
multiples there of. So why would PC manufacturers who habitually target
SOHO users that won't pay for more expensive systems want to try to
peddle more expensive systems?
Especially when web scale companies have proven that thousands of lower
end architectures (compared to the aforementioned alternatives) can
scale and be quite economical for massive computation.
> Most of modern software can be re-compiled for the new instruction sets.
Recompiling is a possibility. But it's not a likely path.
> Tell me why Intel should *not* adopt these architectures; not really why
> Intel does not...
Because Intel can't do it legally. Not without buying / licensing
intellectual property.
There is another CPU architecture that is actually similar to the
aforementioned architectures that is in fact revolutionizing the
industry. ARM.<CPU drop>
--
Grant. . . .
unix || die
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366761 is a reply to message #366759] |
Tue, 24 April 2018 23:45 |
|
|
Originally posted by: Grant Taylor
On 04/24/2018 09:33 PM, J. Clarke wrote:
> And of those the only one that sells is x86. So come up with a
> convincing argument that some other architecture will actually sell
> enough units to be worth the cost of development.
ARM
It's my understanding that Windows will run on a Raspberry Pi 3 which
has an ARM v8 CPU.
--
Grant. . . .
unix || die
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366768 is a reply to message #366760] |
Wed, 25 April 2018 04:36 |
Andy Burns
Messages: 416
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
Grant Taylor wrote:
> Alpha was developed by DEC, purchased by Compaq and subsequently HP.
> Thus HP owns the Intellectual Property of the Alpha CPUs.
Which it subsequently sold to Intel
> I would be somewhat surprised if there aren't pieces of Alpha
> architecture deep in the bowels of other CPU architectures.
AMD licensed the alpha's EV6 bus
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366769 is a reply to message #366760] |
Wed, 25 April 2018 04:50 |
|
|
Originally posted by: David Wade
On 25/04/2018 04:43, Grant Taylor wrote:
> On 04/24/2018 01:43 PM, Charles Richmond wrote:
>> The Tahoe architecture and the DEC Alpha architecture both are much
>> nicer on the assembly level than the x86 architecture. Not many here
>> would disagree with that. Why does Intel *not* produce modern versions
>> of those architectures and PC makers use those???
>
> I'm not familiar with Tahoe and can't comment.
>
> Alpha was developed by DEC, purchased by Compaq and subsequently HP.
> Thus HP owns the Intellectual Property of the Alpha CPUs. — At least
> the portion that did not get sold off to other companies. — I would be
> somewhat surprised if there aren't pieces of Alpha architecture deep in
> the bowels of other CPU architectures.
>
> I'm not a programmer myself, much less an assembly programmer, so I
> can't say with confidence. But it is my understanding that the PDP /
> VAX were meant to be nice to the assembly programmers. x86, not so much
> so.
>
> IMHO, x86 is the Ethernet of CPU architectures, cheap, easy, (made to
> be) fast, prolific. None of those things mean that they are superior.
> (Speed is debatable.)
>
> Intel does not own the Intellectual Property nor are they likely to
> license it.
>
> Also, what would a modern version of the aforementioned CPUs be. I
> suspect the x86 architecture is quite a bit different now compared to
> what it was in the mid '90s.
>
> All of the systems I ever saw that used the other architectures were at
> least one order of magnitude more expensive than the x86 machine, if not
> multiples there of. So why would PC manufacturers who habitually target
> SOHO users that won't pay for more expensive systems want to try to
> peddle more expensive systems?
>
> Especially when web scale companies have proven that thousands of lower
> end architectures (compared to the aforementioned alternatives) can
> scale and be quite economical for massive computation.
>
>> Most of modern software can be re-compiled for the new instruction sets.
>
> Recompiling is a possibility. But it's not a likely path.
>
>> Tell me why Intel should *not* adopt these architectures; not really
>> why Intel does not...
>
> Because Intel can't do it legally. Not without buying / licensing
> intellectual property.
>
> There is another CPU architecture that is actually similar to the
> aforementioned architectures that is in fact revolutionizing the
> industry. ARM.<CPU drop>
>
>
>
ARM is to me interesting. I recently attended a talk on the history of
the ARM by Steve Furber who was along with Sophie Wilson one of the
co-developers of the ARM chips.
He says ARM was developed to be fast and as a consequence was not easy
to program in assembler. Steve Furber says this makes sense because good
compilers remove the need for programmers to understand the chip, and if
the chip is fast the code will be fast.
I suspect many on here will not agree.
Its also interesting to note that ARM does not make CPU's. It licences
the IP to other companies to make the CPU's
Dave
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366773 is a reply to message #366758] |
Wed, 25 April 2018 06:36 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
It is true that today we have just-in-time compilation techniques that
reduce the overhead of simulating other architectures in software.
It's not true that they're 100% efficient or 100% guaranteed to work
perfectly with every piece of existing shrink-wrapped software.
Which is the reason almost nobody would want to bother with a computer
with a different CPU.
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366775 is a reply to message #366761] |
Wed, 25 April 2018 07:13 |
|
|
Originally posted by: J. Clarke
On Tue, 24 Apr 2018 21:45:32 -0600, Grant Taylor
<gtaylor@tnetconsulting.net> wrote:
> On 04/24/2018 09:33 PM, J. Clarke wrote:
>> And of those the only one that sells is x86. So come up with a
>> convincing argument that some other architecture will actually sell
>> enough units to be worth the cost of development.
>
> ARM
>
> It's my understanding that Windows will run on a Raspberry Pi 3 which
> has an ARM v8 CPU.
ARM hit a niche in low power applications. Windows exists for it.
Nobody uses Windows on it. Compare real world performance between ARM
and x86 and you'll know why.
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366776 is a reply to message #366773] |
Wed, 25 April 2018 07:14 |
|
|
Originally posted by: J. Clarke
On Wed, 25 Apr 2018 03:36:01 -0700 (PDT), Quadibloc
<jsavard@ecn.ab.ca> wrote:
> It is true that today we have just-in-time compilation techniques that
> reduce the overhead of simulating other architectures in software.
>
> It's not true that they're 100% efficient or 100% guaranteed to work
> perfectly with every piece of existing shrink-wrapped software.
> Which is the reason almost nobody would want to bother with a computer
> with a different CPU.
They're a lot less than 100% efficient--everybody is releasing "metal"
compilers that run on the native architecture rather than an emulation
layer.
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366785 is a reply to message #366759] |
Wed, 25 April 2018 10:01 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> wrote:
> On Tue, 24 Apr 2018 21:27:28 -0600, Grant Taylor
> <gtaylor@tnetconsulting.net> wrote:
>
>> On 04/24/2018 07:53 PM, J. Clarke wrote:
>>> It does but not the way you mean. Windows NT runs on Alpha, i860,
>>> MIPS R4000, PowerPC, Itanium, and SPARC.
>>
>> Windows NT is from Microsoft, not Intel.
>>
>> You also missed x86 and x86_64 (or x64 if you prefer).
>
> They are assumed.
>
>> Note: Intel makes three of those architectures: x86 (x64), i860
>> (i960), and Itanium.
>
> And of those the only one that sells is x86. So come up with a
> convincing argument that some other architecture will actually sell
> enough units to be worth the cost of development.
>
Chicken-and-egg problem. No matter how excellent the architecture it isn't
going to sell unless the software is there for it. Conversely, no one is
going to develop the software for something that people aren't going to
buy. Linux short-circuits this; as mentioned, just re-compile your programs
for the new architecture (and hope for no compatibility problems)
The other problem is that the architecture is only part of the chip.
Microcode does lots of things behind the scenes to make the chips faster,
less power-hungry, etc., and lots of effort goes into this. Apple said as
much when they switched from PPC to Intel (a mistake in MO, but what do I
know). They couldn't see getting the performance improvements they wanted
out of the PPC over time.
--
Pete
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366791 is a reply to message #366775] |
Wed, 25 April 2018 13:16 |
|
|
Originally posted by: Grant Taylor
On 04/25/2018 05:13 AM, J. Clarke wrote:
> ARM hit a niche in low power applications. Windows exists for it.
> Nobody uses Windows on it. Compare real world performance between ARM
> and x86 and you'll know why.
That's what has been done.
I've seen a number of things where people are experimenting with scaling
ARM architecture up to be higher power / capability CPUs.
--
Grant. . . .
unix || die
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366794 is a reply to message #366791] |
Wed, 25 April 2018 13:48 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Wed, 25 Apr 2018 11:16:37 -0600
Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 04/25/2018 05:13 AM, J. Clarke wrote:
>> ARM hit a niche in low power applications. Windows exists for it.
>> Nobody uses Windows on it. Compare real world performance between ARM
>> and x86 and you'll know why.
>
> That's what has been done.
>
> I've seen a number of things where people are experimenting with scaling
> ARM architecture up to be higher power / capability CPUs.
What you mean things like the Cavium ThunderX - 48 cores running at
2.5GHz with a stack of high bandwith I/O (PCI-e, 40 Gig Ethernet, ...).
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366809 is a reply to message #366791] |
Wed, 25 April 2018 19:55 |
|
|
Originally posted by: J. Clarke
On Wed, 25 Apr 2018 11:16:37 -0600, Grant Taylor
<gtaylor@tnetconsulting.net> wrote:
> On 04/25/2018 05:13 AM, J. Clarke wrote:
>> ARM hit a niche in low power applications. Windows exists for it.
>> Nobody uses Windows on it. Compare real world performance between ARM
>> and x86 and you'll know why.
>
> That's what has been done.
>
> I've seen a number of things where people are experimenting with scaling
> ARM architecture up to be higher power / capability CPUs.
And when they do and it's cost effective get back to us.
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366826 is a reply to message #366725] |
Thu, 26 April 2018 09:54 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Charles Richmond <numerist@aquaporin4.com> writes:
> The Tahoe architecture and the DEC Alpha architecture both are much
> nicer on the assembly level than the x86 architecture. Not many here
> would disagree with that. Why does Intel *not* produce modern versions
> of those architectures and PC makers use those???
Because others have. ARMv8 and PowerPC are two examples.
>
> Most of modern software can be re-compiled for the new instruction sets.
At enormous expense.
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366827 is a reply to message #366752] |
Thu, 26 April 2018 09:55 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> writes:
> On 24 Apr 2018 19:52:13 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
> wrote:
>
>> On 2018-04-24, Charles Richmond <numerist@aquaporin4.com> wrote:
>>
>>> The Tahoe architecture and the DEC Alpha architecture both are much
>>> nicer on the assembly level than the x86 architecture. Not many here
>>> would disagree with that. Why does Intel *not* produce modern versions
>>> of those architectures and PC makers use those???
>>>
>>> Most of modern software can be re-compiled for the new instruction sets.
>>>
>>> Tell me why Intel should *not* adopt these architectures; not really why
>>> Intel does not...
>>
>> I suspect that the answer begins with a dollar sign.
>
> It does but not the way you mean. Windows NT runs on Alpha, i860,
> MIPS R4000, PowerPC, Itanium, and SPARC.
Windows 10 runs on x86 and ARMv8. Not any of the aforementioned
dead processor architectures.
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366828 is a reply to message #366760] |
Thu, 26 April 2018 09:59 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Grant Taylor <gtaylor@tnetconsulting.net> writes:
> On 04/24/2018 01:43 PM, Charles Richmond wrote:
>> The Tahoe architecture and the DEC Alpha architecture both are much
>> nicer on the assembly level than the x86 architecture. Not many here
>> would disagree with that. Why does Intel *not* produce modern versions
>> of those architectures and PC makers use those???
>
> I'm not familiar with Tahoe and can't comment.
>
> Alpha was developed by DEC, purchased by Compaq and subsequently HP.
> Thus HP owns the Intellectual Property of the Alpha CPUs. — At least
> the portion that did not get sold off to other companies. — I would be
> somewhat surprised if there aren't pieces of Alpha architecture deep in
> the bowels of other CPU architectures.
Many of the Alpha folks ended up at Cavium.
Most programmers didn't like alpha at all. The weakly-ordered
memory model and non-coherent DMA caused too many problems,
especially for kernel people.
And nobody cares about the underlying instruction set anymore
because nobody (relative to the entire mass of programmers in
existence) programs in assembler in modern times.
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366829 is a reply to message #366769] |
Thu, 26 April 2018 10:03 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
David Wade <g4ugm@dave.invalid> writes:
> On 25/04/2018 04:43, Grant Taylor wrote:
>
>> There is another CPU architecture that is actually similar to the
>> aforementioned architectures that is in fact revolutionizing the
>> industry. ARM.<CPU drop>
>>
>>
>>
> ARM is to me interesting. I recently attended a talk on the history of
> the ARM by Steve Furber who was along with Sophie Wilson one of the
> co-developers of the ARM chips.
>
> He says ARM was developed to be fast and as a consequence was not easy
> to program in assembler. Steve Furber says this makes sense because good
> compilers remove the need for programmers to understand the chip, and if
> the chip is fast the code will be fast.
>
> I suspect many on here will not agree.
Actually, ARM removed all the goofy predication stuff when
they developed the 64-bit ARM version 8 ISA. It turned out
that the predication stuff (i.e. conditionally executing instructions
based on the condition flags from the prior instruction) makes both
speculation and out-of-order much more difficult and less performant.
As it is, the ARMv8 architecture manual is currently a 6,666 page
PDF with hundreds of instructions (hardly a 'reduced' instruction set
computer any more). Add the coresight, interrupt controller and
IOMMU documentation and you're pushing 10,000 pages.
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366830 is a reply to message #366773] |
Thu, 26 April 2018 10:05 |
Charles Richmond
Messages: 2754
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On 4/25/2018 5:36 AM, Quadibloc wrote:
> It is true that today we have just-in-time compilation techniques that
> reduce the overhead of simulating other architectures in software.
>
> It's not true that they're 100% efficient or 100% guaranteed to work
> perfectly with every piece of existing shrink-wrapped software.
> Which is the reason almost nobody would want to bother with a computer
> with a different CPU.
>
Name one program sold by Microsoft that is "100% guaranteed to work
perfectly". Seems to me this is a specious argument...
--
numerist at aquaporin4 dot com
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366831 is a reply to message #366760] |
Thu, 26 April 2018 10:13 |
Charles Richmond
Messages: 2754
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On 4/24/2018 10:43 PM, Grant Taylor wrote:
> On 04/24/2018 01:43 PM, Charles Richmond wrote:
>> The Tahoe architecture and the DEC Alpha architecture both are much
>> nicer on the assembly level than the x86 architecture. Not many here
>> would disagree with that. Why does Intel *not* produce modern versions
>> of those architectures and PC makers use those???
>
> I'm not familiar with Tahoe and can't comment.
>
> Alpha was developed by DEC, purchased by Compaq and subsequently HP.
> Thus HP owns the Intellectual Property of the Alpha CPUs. — At least
> the portion that did not get sold off to other companies. — I would be
> somewhat surprised if there aren't pieces of Alpha architecture deep in
> the bowels of other CPU architectures.
>
According to the Wikipedia artilce on Alpha: "On June 25, 2001, Compaq
announced that Alpha would be phased out by 2004 in favor of Intel's
Itanium, canceled the planned EV8 chip, and sold all Alpha intellectual
property to Intel." See the following <zdnet.com> article:
https://tinyurl.com/y8m4kqtm
--
numerist at aquaporin4 dot com
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366857 is a reply to message #366830] |
Thu, 26 April 2018 19:49 |
|
|
Originally posted by: J. Clarke
On Thu, 26 Apr 2018 09:05:20 -0500, Charles Richmond
<numerist@aquaporin4.com> wrote:
> On 4/25/2018 5:36 AM, Quadibloc wrote:
>> It is true that today we have just-in-time compilation techniques that
>> reduce the overhead of simulating other architectures in software.
>>
>> It's not true that they're 100% efficient or 100% guaranteed to work
>> perfectly with every piece of existing shrink-wrapped software.
>> Which is the reason almost nobody would want to bother with a computer
>> with a different CPU.
>>
>
> Name one program sold by Microsoft that is "100% guaranteed to work
> perfectly". Seems to me this is a specious argument...
Name one program sold by _anybody_ that is "100% guaranteed to work
pefectly".
|
|
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366900 is a reply to message #366857] |
Fri, 27 April 2018 10:18 |
Charles Richmond
Messages: 2754
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On 4/26/2018 6:49 PM, J. Clarke wrote:
> On Thu, 26 Apr 2018 09:05:20 -0500, Charles Richmond
> <numerist@aquaporin4.com> wrote:
>
>> On 4/25/2018 5:36 AM, Quadibloc wrote:
>>> It is true that today we have just-in-time compilation techniques that
>>> reduce the overhead of simulating other architectures in software.
>>>
>>> It's not true that they're 100% efficient or 100% guaranteed to work
>>> perfectly with every piece of existing shrink-wrapped software.
>>> Which is the reason almost nobody would want to bother with a computer
>>> with a different CPU.
>>>
>>
>> Name one program sold by Microsoft that is "100% guaranteed to work
>> perfectly". Seems to me this is a specious argument...
>
> Name one program sold by _anybody_ that is "100% guaranteed to work
> pefectly".
>
So working perfectly is a red herring in both these regards...
--
numerist at aquaporin4 dot com
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366902 is a reply to message #366881] |
Fri, 27 April 2018 10:27 |
|
|
Originally posted by: drb
>> Name one program sold by _anybody_ that is "100% guaranteed to work
> > pefectly".
> /bin/true
The common linux version of /bin/true these days uses locale,
..po files, parses command line arguments, ...
I sincerely doubt all of that comes anywhere near 100%.
#include <iefbr14>
De
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366908 is a reply to message #366902] |
Fri, 27 April 2018 10:39 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
drb@ihatespam.msu.edu (Dennis Boone) writes:
>>> Name one program sold by _anybody_ that is "100% guaranteed to work
>>> pefectly".
>
>> /bin/true
>
> The common linux version of /bin/true these days uses locale,
> .po files, parses command line arguments, ...
>
> I sincerely doubt all of that comes anywhere near 100%.
Looks like just the basic stuff:
\> ldd /bin/true
linux-vdso.so.1 (0x00007ffcc69d3000)
libc.so.6 => /lib64/libc.so.6 (0x00007f5648bd8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f56491b8000)
"true" is a bash builtin so the "linux version" is NOT /bin/true.
--
Dan Espen
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366913 is a reply to message #366908] |
Fri, 27 April 2018 10:58 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> writes:
> drb@ihatespam.msu.edu (Dennis Boone) writes:
>
>>>> Name one program sold by _anybody_ that is "100% guaranteed to work
>>>> pefectly".
>>
>>> /bin/true
>>
>> The common linux version of /bin/true these days uses locale,
>> .po files, parses command line arguments, ...
>>
>> I sincerely doubt all of that comes anywhere near 100%.
>
> Looks like just the basic stuff:
>
> \> ldd /bin/true
> linux-vdso.so.1 (0x00007ffcc69d3000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f5648bd8000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f56491b8000)
>
> "true" is a bash builtin so the "linux version" is NOT /bin/true.
Bin true does nothing more than exit.
$ ltrace true
__libc_start_main(0x401260, 1, 0x7fff32d19f28, 0x403420, 0x403410 <unfinished ...>
exit(0 <unfinished ...>
+++ exited (status 0) +++
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366914 is a reply to message #366902] |
Fri, 27 April 2018 10:46 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Fri, 27 Apr 2018 09:27:16 -0500
drb@ihatespam.msu.edu (Dennis Boone) wrote:
>>> Name one program sold by _anybody_ that is "100% guaranteed to work
>>> pefectly".
>
>> /bin/true
>
> The common linux version of /bin/true these days uses locale,
> .po files, parses command line arguments, ...
Wow! Why ?
Apart from comments the BSD version of true is:
int
main(void)
{
return 0;
}
It used to be an executable empty file but this is lighter than
invoking a shell just to return 0.
> I sincerely doubt all of that comes anywhere near 100%.
I think the BSD one does.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366931 is a reply to message #366908] |
Fri, 27 April 2018 14:41 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> drb@ihatespam.msu.edu (Dennis Boone) writes:
>
>>>> Name one program sold by _anybody_ that is "100% guaranteed to work
>>>> pefectly".
>>
>>> /bin/true
>>
>> The common linux version of /bin/true these days uses locale,
>> .po files, parses command line arguments, ...
>>
>> I sincerely doubt all of that comes anywhere near 100%.
>
> Looks like just the basic stuff:
>
> \> ldd /bin/true
> linux-vdso.so.1 (0x00007ffcc69d3000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f5648bd8000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f56491b8000)
>
> "true" is a bash builtin so the "linux version" is NOT /bin/true.
>
IEFBR14 (after last APAR).
--
Pete
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366958 is a reply to message #366914] |
Fri, 27 April 2018 17:33 |
Charles Richmond
Messages: 2754
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On 4/27/2018 9:46 AM, Ahem A Rivet's Shot wrote:
> On Fri, 27 Apr 2018 09:27:16 -0500
> drb@ihatespam.msu.edu (Dennis Boone) wrote:
>
>>>> Name one program sold by _anybody_ that is "100% guaranteed to work
>>>> pefectly".
>>
>>> /bin/true
>>
>> The common linux version of /bin/true these days uses locale,
>> .po files, parses command line arguments, ...
>
> Wow! Why ?
>
> Apart from comments the BSD version of true is:
>
> int
> main(void)
> {
> return 0;
> }
>
> It used to be an executable empty file but this is lighter than
> invoking a shell just to return 0.
>
>> I sincerely doubt all of that comes anywhere near 100%.
>
> I think the BSD one does.
>
True should return *one*... zero is false.
--
numerist at aquaporin4 dot com
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366962 is a reply to message #366958] |
Fri, 27 April 2018 19:39 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Fri, 27 Apr 2018 16:33:29 -0500
Charles Richmond <numerist@aquaporin4.com> wrote:
> On 4/27/2018 9:46 AM, Ahem A Rivet's Shot wrote:
>> On Fri, 27 Apr 2018 09:27:16 -0500
>> drb@ihatespam.msu.edu (Dennis Boone) wrote:
>>
>>>> > Name one program sold by _anybody_ that is "100% guaranteed to
>>>> > work pefectly".
>>>
>>>> /bin/true
>>>
>>> The common linux version of /bin/true these days uses locale,
>>> .po files, parses command line arguments, ...
>>
>> Wow! Why ?
>>
>> Apart from comments the BSD version of true is:
>>
>> int
>> main(void)
>> {
>> return 0;
>> }
>>
>> It used to be an executable empty file but this is lighter than
>> invoking a shell just to return 0.
>>
>>> I sincerely doubt all of that comes anywhere near 100%.
>>
>> I think the BSD one does.
>>
>
> True should return *one*... zero is false.
In C yes, but the value returned by main is handed to the execution
environment, in this case a shell where 0 is true and any non-zero value
false.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366980 is a reply to message #366908] |
Fri, 27 April 2018 22:38 |
|
|
Originally posted by: Grant Taylor
On 04/27/2018 08:39 AM, Dan Espen wrote:
> "true" is a bash builtin so the "linux version" is NOT /bin/true.
"true" may be a built in, but "/bin/true" is not. ;-)
It depends how you call the command.
alias true='/bin/false' }:-)
--
Grant. . . .
unix || die
|
|
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #366982 is a reply to message #366908] |
Sat, 28 April 2018 00:10 |
|
|
Originally posted by: drb
> \> ldd /bin/true
> linux-vdso.so.1 (0x00007ffcc69d3000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f5648bd8000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f56491b8000)
> "true" is a bash builtin so the "linux version" is NOT /bin/true.
Skipping over the people that don't use bash, and the scripts that
use /bin/true rather than the builtin, ...
int
main (int argc, char **argv)
{
/* Recognize --help or --version only if it's the only command-line
argument. */
if (argc == 2)
{
initialize_main (&argc, &argv);
set_program_name (argv[0]);
setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
/* Note true(1) will return EXIT_FAILURE in the
edge case where writes fail with GNU specific options. */
atexit (close_stdout);
if (STREQ (argv[1], "--help"))
usage (EXIT_STATUS);
if (STREQ (argv[1], "--version"))
version_etc (stdout, PROGRAM_NAME, PACKAGE_NAME, Version, AUTHORS,
(char *) NULL);
}
return EXIT_STATUS;
}
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #367000 is a reply to message #366982] |
Sat, 28 April 2018 06:11 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Fri, 27 Apr 2018 23:10:41 -0500
drb@ihatespam.msu.edu (Dennis Boone) wrote:
>> \> ldd /bin/true
>> linux-vdso.so.1 (0x00007ffcc69d3000)
>> libc.so.6 => /lib64/libc.so.6 (0x00007f5648bd8000)
>> /lib64/ld-linux-x86-64.so.2 (0x00007f56491b8000)
>
>> "true" is a bash builtin so the "linux version" is NOT /bin/true.
>
> Skipping over the people that don't use bash, and the scripts that
> use /bin/true rather than the builtin, ...
>
> int
> main (int argc, char **argv)
> {
> /* Recognize --help or --version only if it's the only command-line
> argument. */
> if (argc == 2)
> {
> initialize_main (&argc, &argv);
> set_program_name (argv[0]);
> setlocale (LC_ALL, "");
> bindtextdomain (PACKAGE, LOCALEDIR);
> textdomain (PACKAGE);
>
> /* Note true(1) will return EXIT_FAILURE in the
> edge case where writes fail with GNU specific options. */
> atexit (close_stdout);
>
> if (STREQ (argv[1], "--help"))
> usage (EXIT_STATUS);
>
> if (STREQ (argv[1], "--version"))
> version_etc (stdout, PROGRAM_NAME, PACKAGE_NAME, Version, AUTHORS,
> (char *) NULL);
> }
>
> return EXIT_STATUS;
> }
I far prefer the BSD version.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: Tahoe and Alpha Architectures [message #367003 is a reply to message #366962] |
Sat, 28 April 2018 06:40 |
|
|
Originally posted by: Kerr-Mudd,John
On Fri, 27 Apr 2018 23:39:27 GMT, Ahem A Rivet's Shot <steveo@eircom.net>
wrote:
> On Fri, 27 Apr 2018 16:33:29 -0500
> Charles Richmond <numerist@aquaporin4.com> wrote:
>
>> On 4/27/2018 9:46 AM, Ahem A Rivet's Shot wrote:
>>> On Fri, 27 Apr 2018 09:27:16 -0500
>>> drb@ihatespam.msu.edu (Dennis Boone) wrote:
>>>
>>>> > > Name one program sold by _anybody_ that is "100% guaranteed
to
>>>> > > work pefectly".
>>>>
>>>> > /bin/true
>>>>
>>>> The common linux version of /bin/true these days uses locale,
>>>> .po files, parses command line arguments, ...
>>>
>>> Wow! Why ?
>>>
>>> Apart from comments the BSD version of true is:
>>>
>>> int
>>> main(void)
>>> {
>>> return 0;
>>> }
>>>
>>> It used to be an executable empty file but this is lighter than
>>> invoking a shell just to return 0.
>>>
>>>> I sincerely doubt all of that comes anywhere near 100%.
>>>
>>> I think the BSD one does.
>>>
>>
>> True should return *one*... zero is false.
>
> In C yes, but the value returned by main is handed to the
execution
> environment, in this case a shell where 0 is true and any non-zero
value
> false.
>
-1 is true all else is false. Bring back ones complement! </loony
heretic>
--
Bah, and indeed, Humbug.
|
|
|
|
Members
Search
Help
Register
Login
Home
