On Oct 3, 6:30 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
> Sun has many assets; some people had thought that Java would be the
> future of computing, for example. But spending money to squelch an
> open-source competitor is a waste of money, since it can be forked. (I
> assume the MySQL code, even if it's more efficient than Postgres code,
> is not something Oracle needed to buy so it could incorporate it into
> its proprietary products without licensing it under the GPL - it
> wasn't running rings around Oracle or anything like that, was it?)
I don't care all that much about RDBMSes but that does not prevent me
from having my own opinion about why MySQL is important for Oracle ;)
It's not because they could make money out of it by selling support
etc...
And it's not because that way they could be sure that MySQL wouldn't
suddenly become performance competitive with their main line.
The reason, IMHO, that well-being of MySQL prevents absolute dominance
of Microsoft SQL Server Express on the ultra-low end.
And why is it good for Oracle? Because many users that started with
ultra-low end RDBMS outgrow it in a few years and then look for
professional product. Those that started with SQL Server Express are
far more likely to migrate to professional RDBMS from the same
Microsoft family than switch to Oracle (or DB2, for that matter). On
the other hand, users that outgrew MySQL are open in their migration
choice and far more likely to end up in Larry's hands.
Walter Banks wrote:
> Pulling some of your comments out of context. One of the effects of
> open source development tools is the technology they use is dated.
> The open source tools cherry pick customers that compiler performance
> doesn't significantly matter.
This is one of the key insights you can have today, i.e. for most problems you just need to minimize the amount of data loaded from/stored back to actual RAM, since cache misses often dominate.
> Saying that is not to restart the argument
> of commercial vs open source. The effect is the available resources
> to continue to extend our tools is limited by the potential customer
> base that would use and pay for the tools.
> I agree with many (most) of your comments about compiler technology.
> There is another comment on asm and that is just using asm will not
> add to application performance, it takes an exceptional asm
> programmer to get the performance you are describing. Personally
As usual, the real "trick" is to be able to improve the algorithm used, i.e. writing asm is (at least for me these days) mostly a necessary step on the way to really understand what the actual problem is.
> I am interested in details of asm tricks to improve code generation
> and application development. The fact that it is possible reflects on
> the state of compilers where computing processor power is essentially
> free.
> We have implemented strategy passes to at least understand data
> flow in application code. For the processors that we support I can
> write (and prove) that a C program will equal or better metrics that
> any asm program for the same processor.
Wow!!!
Can you give any kind of example?
The only compiler intrinsics
> needed is access to the condition codes in our compilers. There are
> a lot of simple things that compilers in general don't do for example
> is the whole ISA being used and is instruction limitations implemented
> as part of the code generator.
The last compiler I heard about which used the entire instruction set of the target cpu was a Cobol compiler that would even use all the ascii/BCD instructions on an x86.
This does of course prove that they didn't actually know how to optimize their code, since using those opcodes to process single BCD digits have always been much slower than SIMD style code that packs 4 or 8 digits into a 32-bit register.
Terje
-- - <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
> On Oct 3, 8:52 am, Michael S <already5cho...@yahoo.com> wrote:
> > "if *Intel* had bought *Oracle*" by now sounds like rather funny idea.
> > Intel and Oracle are about the same size, by nearly all measures,
> > including, most importantly, net income.
> Oh. In that case, it is not entirely madness for Oracle to be trying
> to compete head-to-head with IBM.
> Sun has many assets; some people had thought that Java would be the
> future of computing, for example. But spending money to squelch an
> open-source competitor is a waste of money, since it can be forked. (I
> assume the MySQL code, even if it's more efficient than Postgres code,
> is not something Oracle needed to buy so it could incorporate it into
> its proprietary products without licensing it under the GPL - it
> wasn't running rings around Oracle or anything like that, was it?)
> But when I tried to think about what could possibly relate to Oracle's
> core business, the idea of SPARC-based hardware running Oracle
> databases to head off against IBM hardware running IBM databases made
> a sort of sense.
> However, shortly *after* Oracle bought Sun, Intel went and brought out
> the EX series of Xeon chips, so that RAS features, heretofore only
> available from Intel on the Itanium (which many fear could someday be
> orphaned) made it to the x86 platform.
> My reaction at the time, which I see little reason to change, is that
> *that* meant that Oracle had wasted its money. (SPARC-based chips from
> Sun had already had RAS features, making them applicable to such a
> plan.)
RAS stands for "Reliability, Accessibility, Serviceability".
I don't think that, by the time of acquisition, Sun's SPARC-based
chips had anything of those three above what was available in Intel's
Dunnington Xeon-MP. Sparc-T (a.k.a. Niagara) line had more modern
system architecture, better per-chip throughput and, probably, better
power efficiency, but RAS? I don't think they were even equal to
Dunnington, let alone better.
So, on that front, appearance of Beckton (Nehalem-EX) changed little.
BTW, the idea that contemporary Itanium (i.e. Montvale) had
significant head start over Dunnington in RAS department also appears
questionable. HP Integrity Superdome did have RAS features unavailable
in HP Proliant servers, but the main difference was in chipset, not in
CPU. More back-to-earth HP Integrity lines i.e. rackable servers and
blades had RAS more or less identical to Proliant DL580-G5.
> > I am interested in details of asm tricks to improve code generation
> > and application development. The fact that it is possible reflects on
> > the state of compilers where computing processor power is essentially
> > free.
> > We have implemented strategy passes to at least understand data
> > flow in application code. For the processors that we support I can
> > write (and prove) that a C program will equal or better metrics that
> > any asm program for the same processor.
> Wow!!!
> Can you give any kind of example?
> > The only compiler intrinsics
> > needed is access to the condition codes in our compilers.
The proof essentially is can I code the whole instruction set in C
and will it compile to the ISA. I am not talking about intrinsics
except for full access to the processor. For example add plus
the carry should generate ADC . Rotates and shifts need to
handled in similar way. We have typically created a structure to
access condition codes..
Actually we access to the processor registers as well as condition
codes in the C to ISA tests. (ISO/IEC 18037 which I co-wrote)
The important thing is the compiler optimizer recognizes how to use
the whole ISA and not implement some compiler trick. We first
did this as a way to create a metric to identify progress in a compiler
implementation. The side effect is all of the code generation
improved.
A second use has been to do this as part of ISA development,
it this better than most approaches has helped identify useful
instructions and data flow issues,
I agree that algorithm improvements have the most significant
impact on benchmarks.
Compiled code does have an advantage over assembly code
in that implementation details can be sorted out by the compiler
everytime the application is built. It also speaks that language
design should focus on application algorithms.
In article <k4fkem$fo...@dont-email.me>, SF...@alumni.cmu.edu.invalid
(Stephen Fuld) wrote:
> There is some dispute, but both give the availability of lower cost > peripherals as one of the reasons.
Another reason was time. 8 bit peripheral chips were available in quantity production, 16 bit chips were not widely available when the PC was designed.
In article <5c1c3a86-1e2e-482d-a559-4c1c4f608...@w2g2000vbc.googlegroups.com>,
already5cho...@yahoo.com (Michael S) wrote:
> 8080 was source-code compatible to 8008 (which ISA was designed by
> CTC), but not binary compatible.
The 8080 bore a similar relationship to 8008 as the Z80 did to the 8080. It could run existing 8008 code but it added a lot more if the code was rewritten to use the extended instruction set. For a start the 8080 added direct memory access instead of having to use HL.
On Oct 3, 4:18 am, Stephen Sprunk <step...@sprunk.org> wrote:
> That ISA was a hack of CTC's 8080 ISA plus segmentation, which plagued
> the PC world for two decades.
Out of curiosity I took a look at 8008 ISA. I suggest you to do the
same. 8086 is about as similar to 8008 as any other randomly picked 16-
bitter is similar to randomly picked 8-bitter.
For starter, 8008 is accumulator machine with inc, dec and mov being
the only operations that don't have to have an accumulator as one of
the sources and destination. 8086 is, of course, 2-address machine for
majority of operations. More so, in 8086 memory location could serve
as destination of most common ALU/Logical operations.
8008 has exactly one memory addressing mode - indirect with address in
the predefined pair of 8-bit registers. 8086 has many memory
addressing modes, even unusually many for such tiny machine.
8008 has small on-chip call/return stack. 8086 has call/return stack
in external memory.
8008 conditional branches specify absolute address of the target. 8086
conditional branches are PC-relative.
8008 only has direct jumps and calls. 8086 has direct jumps and calls
plus two forms of indirect jumps and calls.
8008 has conditional call instruction. 8086 does not have conditional
call instruction.
8008 conditional branches governed by 8 conditional codes mapped one-
to-one to 4 arithmetic flags. 8086 has 16 condition codes. Some of
them are mapped to a single flag, but many look at combination of two
flags.
So, the two ISAs are dissimilar in seven most basic aspects. I wonder
how could you say that the one is a hack of the other?
Of course, if one looks really hard, it could find some similarities.
E.g:
8008 has 7 8-bit registers, 8086 has 7 16-bit registers + 16-bit stack
pointer.
8008 has ZSCP arithmetic flags. 8086 has ZSCP plus A and O flags.
8008 does not update arithmetic flags on load/store/move. Nor does
8086
8008 does not update carry flag on inc/dec.. Nor does 8086.
8008 instruction are variable-length with byte granularity (1, 2 or 3
bytes). Same for 8086, except there are far more possible lengths.
But, as I said, similarities like those could be found in just about
any pair of ISAs, especially designed in the same time frame.
>> 8080 was source-code compatible to 8008 (which ISA was designed by
>> CTC), but not binary compatible.
> The 8080 bore a similar relationship to 8008 as the Z80 did to the > 8080. It could run existing 8008 code but it added a lot more if the > code was rewritten to use the extended instruction set. For a start the > 8080 added direct memory access instead of having to use HL.
My understanding is that the Z80 was binary backward compatible with the
8080 (never looked in detail at Z80, hence my careful wording). The
8080 was *not* binary backward compatible with the 8008.
On Wed, 03 Oct 2012 16:53:42 -0500, ken...@cix.compulink.co.uk wrote:
>In article <k4fkem$fo...@dont-email.me>, SF...@alumni.cmu.edu.invalid >(Stephen Fuld) wrote:
>> There is some dispute, but both give the availability of lower cost >> peripherals as one of the reasons.
> Another reason was time. 8 bit peripheral chips were available in >quantity production, 16 bit chips were not widely available when the PC >was designed.
That wasn't too much of a problem - most of the peripheral chips were
in fact 8 bit, but 8086 had high and low-byte enables on the data bus
and could drive 8 bit peripheral chips with little effort. In fact
almost everyone who used the 8086 used the standard 8080-style
peripherals. The real problem was doubling the bus would have
required a wider peripheral bus and wider memory, which would have
driven up cost.
On Wed, 03 Oct 2012 16:53:42 -0500, ken...@cix.compulink.co.uk wrote:
>In article ><5c1c3a86-1e2e-482d-a559-4c1c4f608...@w2g2000vbc.googlegroups.com>, >already5cho...@yahoo.com (Michael S) wrote:
>> 8080 was source-code compatible to 8008 (which ISA was designed by
>> CTC), but not binary compatible.
> The 8080 bore a similar relationship to 8008 as the Z80 did to the >8080. It could run existing 8008 code but it added a lot more if the >code was rewritten to use the extended instruction set. For a start the >8080 added direct memory access instead of having to use HL.
Not exactly. The 8080 was source code compatible (at the assembler
level) with the 8008, in that every 8008 instruction could be recoded
as a few 8080 instructions (usually one). The 8086 had a similar
relationship with the 8080, where all but four 8080 instructions could
be coded as one or two instruction 8086 sequences (and those four had
exact replacement sequences, just longer than two instructions).
A number of important programs were ported from CP/M to PC-DOS that
way (Wordstar, for example).
The Z-80 was basically 100% binary compatible with the 8080, but added
a bunch more registers and a bunch more instructions - but you could
take an 8080 OS or application and run it on a Z-80 system without
changes (assuming, of course, that the non-CPU parts of the system
were sufficiently compatible).
Terje Mathisen wrote:
> This is one of the key insights you can have today, i.e. for most
> problems you just need to minimize the amount of data loaded from/stored
> back to actual RAM, since cache misses often dominate.
It is still the most common problem, but cache line sharing (false
and designed explicitely) is currently becomming an important and
painful problem too. Recently we have increased scalability of our
product from 6x to 32x using several simple tricks. There was a shared
hash table implemented when the most paralllel of our machines had
only 4 CPUs, so there no way to figure it out then and later everyone
have forgotten about its existence. :-)
BTW, I would like to falsify the current religion that
memory is essentially free. But your cache isn't. :-)
> As usual, the real "trick" is to be able to improve the algorithm used,
> i.e. writing asm is (at least for me these days) mostly a necessary step
> on the way to really understand what the actual problem is.
I still make a living writing in asm, but it is mostly SIMD-related.
For example, it's a must to implement decimal<=>string converters
using vector extensions and the string itself too.
>>> There is some dispute, but both give the availability of lower cost >>> peripherals as one of the reasons.
>> Another reason was time. 8 bit peripheral chips were available in >>quantity production, 16 bit chips were not widely available when the PC >>was designed.
>That wasn't too much of a problem - most of the peripheral chips were
>in fact 8 bit, but 8086 had high and low-byte enables on the data bus
>and could drive 8 bit peripheral chips with little effort. In fact
>almost everyone who used the 8086 used the standard 8080-style
>peripherals. The real problem was doubling the bus would have
>required a wider peripheral bus and wider memory, which would have
>driven up cost.
It wasn't a problem with the 68000 either. There were instructions to read/write 8 bit perpherials, and special memory cycles so that the older 8 bit chips would work.
One of the *real* problems was that Intel had a development platform (with an ICE debugger), Motorola didn't. The other was that there was no 8 bit version, a 32 bit processor (16 bit data bus) that could address 16 MB of memory was clearly competition to IBM's sacred mainframes (at least the low end). I wouldn't be surprised if internal politics killed that possibility.
> Stephen Sprunk wrote:
>> There's an interesting parallel to English, which is arguably the most
>> complex and hideous language to ever exist. It didn't start out that
>> way, though. If you understand the evolution and influences, it
>> actually does make quite a bit of sense--just not if you try to
>> understand its modern form all at once in a vacuum.
> This is a quite good British documentary on this called
> "The Adventure of English", 8 episodes of 50 minutes each.
> It traces English from its roots in Friesland, Netherlands
> 1500 years ago to modern day.
That looks very interesting; thank you for the reference.
S
-- Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
On Oct 3, 1:45 pm, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> Walter Banks wrote:
> > For the processors that we support I can
> > write (and prove) that a C program will equal or better metrics that
> > any asm program for the same processor.
> Wow!!!
> Can you give any kind of example?
While that may seem odd, because in theory one can write any program
in assembler, while the possible outputs of a compiler are limited, in
practice this has been true for compilers for some time - since many
types of optimization would require a great deal of effort for someone
writing hand-coded assembler.
As a simple example, normally a hand-coded program will first do one
thing and then do the next thing... while a compiler can interleave
integer instructions and floating-point instructions to take advantage
of a superscalar architecture.
On Thursday, October 4, 2012 1:57:12 PM UTC-5, Quadibloc wrote:
> As a simple example, normally a hand-coded program will first do one > thing and then do the next thing... while a compiler can interleave > integer instructions and floating-point instructions to take advantage > of a superscalar architecture.
Any (ANY) good assembly person can do this kind of code scheduling.
And for the assembler in the 88K family, I wrote the code scheduler.
It takes in 88K assembly code, and produces 88K assembly code that has been rescheduled to the pipelne. So, in this case, the assembly
language programmer does not have to know the pipeline, he can simply
use the assembler to reschedule his code (optionally).
Quadibloc wrote:
> While that may seem odd, because in theory one can write any program
> in assembler, while the possible outputs of a compiler are limited, in
> practice this has been true for compilers for some time - since many
> types of optimization would require a great deal of effort for someone
> writing hand-coded assembler.
That's true, and it is the main reason I don't write asm to get 20% speedups any more.
> As a simple example, normally a hand-coded program will first do one
> thing and then do the next thing... while a compiler can interleave
> integer instructions and floating-point instructions to take advantage
> of a superscalar architecture.
That's an _extremely_ simple example, the AES effort I mentioned a few days ago got to 3X the speed of the C code by (among many other things) completely unrolling and then manually scheduling/interleaving all the instructions from the 8 iterations of the core encryption loop.
In fact, on the Pentium one of the surest ways to beat compilers was by optimally scheduling both fp and int operations, something no compiler was even close to capable of at the time.
Some modern cores, like Atom and Larrabee/MIC, have gone back to the Pentium pair of in-order execution pipelines, so this kind of instruction (micro-)scheduling is getting more important.
Terje
-- - <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
Piotr Wyderski wrote:
> I still make a living writing in asm, but it is mostly SIMD-related.
Yeah, but in those cases pseudo-asm in the form of compiler intrinsics can often do the job pretty well.
> For example, it's a must to implement decimal<=>string converters
> using vector extensions and the string itself too.
Huh?
I thought I had written the ultimate binary-decimal conversion algorithm many years ago, I posted it here (and in clax probably) at the time.
AMD "borrowed" it for their code optimization manual, unfortunately after stripping out my name and all other attribution, then adding a tiny tweak to the last stage.
Anyway, it takes around 30 clock cycles to convert a 32-bit unsigned value to 10 decimal digits.
If you have a faster SIMD way of doing this, I'm interested!
Terje
-- - <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
> Piotr Wyderski wrote:
> > I still make a living writing in asm, but it is mostly SIMD-related.
> Yeah, but in those cases pseudo-asm in the form of compiler intrinsics
> can often do the job pretty well.
> > For example, it's a must to implement decimal<=>string converters
> > using vector extensions and the string itself too.
> Huh?
> I thought I had written the ultimate binary-decimal conversion algorithm
> many years ago, I posted it here (and in clax probably) at the time.
> AMD "borrowed" it for their code optimization manual, unfortunately
> after stripping out my name and all other attribution, then adding a
> tiny tweak to the last stage.
> Anyway, it takes around 30 clock cycles to convert a 32-bit unsigned
> value to 10 decimal digits.
> If you have a faster SIMD way of doing this, I'm interested!
> Terje
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"
Well, not a general case, but application of brute force "add 3"
algorithm (hopefully, I don't need to post exact code here, you would
easily figure it out yourself) to 4 27-bit numbers in range
0..99,999,999 should deliver 4 BCD results in approximately 270 128-
bit AVX instructions that should take (on SandyB/IvyB) something like
150 clock cycles.
The number of clocks does not include loading of constants into xmm
registers that could cost few more cycles in scalar call, but not
significant when you process long vectors.
So, your variant still wins, even on throughput.
But AVX2 is coming. With AVX2 it would be possible to process 8
numbers at time and thus to beat you on throughput by something like
25%.
Now, that's just a direct adaptation of half a century old hardware-
oriented algorithm to software. I didn't try to think about smarter
ways.
eStephen Fuld <SF...@alumni.cmu.edu.invalid> wrote:
> On 10/2/2012 4:22 AM, Stephen Sprunk wrote:
> > On 24-Sep-12 08:48, Anonymous wrote:
> >> It would seem from Intel's other horrific blunders and foolish
> >> missteps over the past decades they were and are relatively hostile
> >> to outside influences and they seem to have gone out of their way
> >> several times to shoot themselves in the foot.
> > Pretty much _every_ ISA that Intel has ever deliberately designed has
> > been a miserable failure. Their successes have been either accidents or
> > a result of copying someone else.
> Intel has had several major successes.
I guess we differ on what success means. Certainly Intel is commercially
successful, but so were Bill Clinton and so is Microsoft. Success doesn't
mean something is good, it means it's well-marketed. Sadly, successful
products are often considerably worse than the alternatives.
Intel has a knack for designing (or adopting) unnecessarily complex ISAs and
implementing them in the lamest ways possible. Simple, elegant designs are
signs of healthy minds. Intel's convoluted horseshit is the product of sick
people. I've seen enough technology and people who make it to make the
connection.
> The original 8080 arguably started the personal computer revolution,
IBM arguably started the personal computer revolution. Given what someone
else reminded us, that nobody sees the ISA much less the actual hardware,
they could have powered it with two soup cans and a piece of
spaghetti. Intel was just lucky to be the soup cans and Microsoft was the
spaghetti. No offense to Cambpells or Italians intended!
> obviously the X86
Very arguably the worst ISA ever "designed"
> and don't forget the 8051, which, by volume, swamps anything else around.
TI painted a big bullseye on the 8051 and its best days are long gone. I
haven't looked at it but if it's like anything else that ever came out of
Intel.. again, commercial success is no indication that something is
actually good or designed properly.
> >> AMD and Intel flubbed the 32 to 64 bit changeover so badly they
> >> still haven't fixed it and it will probably require changes to ELF
> >> and various OS to do it correctly, which isn't going to happen
> >> overnight. Nobody seemed to have a clue on this, and they should have
> >> seen it coming from the 16 bit to 32 bit changeover but they didn't.
> > It's far too late to change x86-64 now; that mistake was pretty much set
> > in stone a decade or so ago.
> >> Intel's instruction encoding is bizarre and complicated in the
> >> extreme.
> > Well, the original ISA made a reasonable amount of sense back when it
> > was designed, but there really wasn't any way to extend it in a
> > reasonable way because, AFAICT, that was never a design consideration.
That's exactly the point. IBM and other manufacturers have been able to
extend their designs without legacy baggage while still being upward
compatible. Intel is incapable of doing this at all. And their embarassing
blunders affect day-to-day use of modern OS that run on Intel designs.
> >> On Intel some
> >> intructions that are available in 16/32 bit mode (AAA comes to mind)
> >> don't work in 64 bit mode,
> > Well, they _did_ need to recover a sizeable chunk of opcode space, and
> > instructions that were rarely/never used anymore or that had redundant
> > encodings were obvious targets.
Why is BCD redundant in 64 bit mode? There's nothing to replace it.
> >> you can't use registers in the wrong mode,
> >> and you can't link an executable that contains programs in different
> >> modes.
> > Nope. While that's a pain during the transitions, it's really not that
> > big a problem overall. Obviously, someone starting from scratch
> > wouldn't have designed it that way, but we can't rewrite history.
You're a lot more forgiving than I am. I find these design fuckups
inexcusable, and I don't agree they're not "big problems overall". Try
living with a pure 32 or 64 bit Linux or UNIX and tell me these aren't real
problems. These non-designs make practical day to day use a living hell when
you have to have two sets of libraries and separate link and load paths for
everything. It's an embarrassment for Intel x86 and the OS that run on
it. But I guess if that is all you know you might not see the problem. Just
so you know, IBM did this right as I described in an earlier post. And they
did it before Intel and AMD started shanking this one. You would have
thought they would pay attention and not make avoidable mistakes.
> >> Given IBM was there first in all cases, and did things seamlessly
> >> and elegantly (and their tech pubs are freely available online) there
> >> really isn't any excuse for Intel's consistent history of embarassing
> >> fuckups.
> Come on now. First of all, IBM wasn't first, Univac, or arguably ABC > was.
In practice, nothing is left of UNIVAC or anything else. IBM set the
standard of doing things right the first time, and actually thinking
ahead. Their designs evolved and are still working, and they didn't subject
their customers to any of the ridiculous hoop-jumping Intel software
engineers have had to put up with.
> Second of all, you are conveniently forgetting all of IBM's > mistakes. For examples, look at the System/1, the System/7, the System > 32/34/36.
Why are those mistakes? They were all upward compatible and they all worked
and sold well (except for S/32 and S/7 which I never head of).
> Even the S/360 architecture has had significant mistakes. For > example, others have mentioned the 16 bit floating point.
It also had 32 and 64 bit floating point. Caveat emptor. Nobody forced you
to use it. Do you want me to list all the broken, idiotic instructions in
the Intel ISA? How much time do you have? And you're not making a valid
comparison. System 360 came out in 1964. What do you want to compare it to?
We're comparing Intel's broken non-designs now, to what else is available
now. Join the discussion!
> Also, I regard the way the the addressing is set up with over half the
> available addressing space taken up by the OS and shared memory, and
> exposing the OS's internal addresses to the user program, thus limiting
> program size and needing kludgy OS support to get around as a mistake.
What are you talking about here and to what are you comparing it? Are you
still back in 1964? Then compare it to a contemporaneous OS...if you can.
There are hardware features that protect everything, something Intel has
never been able to implement. There's no program size limitation and no OS
kludging. If you're talking about OS/360 then compare it to UNIX years
later. You can't compare it to UNIX in 1964, since OS/360 was around a long
time before Bell Lab's first UNIX. At least compare apples and apples.
> >> ... nobody seems to have adopted [IBM's] hardware/software
> >> as a package philosophy except perhaps to a much less extent Sun with
> >> Solaris/SPARC, and that was also a very nice platform.
> All of the other mainframe companies did so. But it takes a huge amount > of resources to do both and those companies have been pushed to the > fringes of the computing world, or out of it altogether.
None of the other mainframe companies did so, and none are left. About all
they were able to do is ripoff IBM IP and make clones. I don't call that
hardware/software as a package.
> > The conventional wisdom is that one company cannot be good at both, so
> > they focus on one and try to commoditize the other. IBM nearly imploded
> > in the 1980s by ignoring that,
That wasn't the reason. It was the economic climate, look at what happened
with the auto manufacturers. It was an era when people started to want cheap
instead of good. IBM and other premium companies never do well in those
environments. You want the best, you have to pay for it. Try getting a deal
on a Ferarri. Maybe they're not good values, but they're damn good cars.
> >> Personally, I'm very sick of Intel's shitty "engineering" and I'm
> >> glad to see other companies and architectures make headway whenever
> >> they can.
> > If were really that "shitty", or purity of design actually mattered to
> > the market, then Intel would be long dead by now.
It is really that shitty, but the 2nd part of what you wrote is why Intel
isn't dead. Really, it's because Microsoft isn't dead. They have a
codependancy and whenever one goes the other is going with it.
> > One could attribute Intel's success _today_ to their market position and
> > questionable tactics, but they _did_ have many larger competitors back
> > in the day and still managed to come out on top, so perhaps there's more
> > to success than ideological (or simply logical) purity.
I'm an engineer not a CFO so I don't care about success as you view it. I
care about doing things right because I like to sleep well and not be part
of the problem. Intel's success is because of Microsoft, specifically
Windows. As Windows goes, so goes Intel. I suspect both will be rather minor
players a decade from now.
> Yup. Including "luck". IBM was originally favoring the 6800 for the > PC, but at the time, Motorola didn't have a part with an 8 bit > interface, which IBM felt it needed to keep system costs down.
<fr...@spamexpire-201210.rodent.frell.theremailer.net> wrote:
> That wasn't the reason. It was the economic climate, look at what happened
> with the auto manufacturers. It was an era when people started to want cheap
> instead of good. IBM and other premium companies never do well in those
> environments. You want the best, you have to pay for it.
Fritz Wuehler wrote:
> Intel has a knack for designing (or adopting) unnecessarily complex ISAs and
> implementing them in the lamest ways possible. Simple, elegant designs are
> signs of healthy minds. Intel's convoluted horseshit is the product of sick
> people. I've seen enough technology and people who make it to make the
> connection.
It must be nice to be perfect and always right.
>> obviously the X86
> Very arguably the worst ISA ever "designed"
The only ISA features that really matters are those that make it hard to run fast, i.e. instructions with multiple/unlimited memory accesses.
> Why is BCD redundant in 64 bit mode? There's nothing to replace it.
And this is where you show that you are not quite infallible:
BCD opcodes to process single ASCII/BCD digits are _way_ slower (an order of magnitude even) than SIMD code which fill an entire register (32/64/128 bits) with digits and work on them all in parallel!
> You're a lot more forgiving than I am. I find these design fuckups
> inexcusable, and I don't agree they're not "big problems overall". Try
> living with a pure 32 or 64 bit Linux or UNIX and tell me these aren't real
> problems. These non-designs make practical day to day use a living hell when
> you have to have two sets of libraries and separate link and load paths for
> everything. It's an embarrassment for Intel x86 and the OS that run on
This has absolutely nothing to do with Intel and the actual x86/x64 cpus they provide, if Linus had cared about making a 64-bit OS which was backwards compatible with 32-bit programs, then they could have employed exactly the same kinds of conversion thunks that IBM used on their mainframes.
Terje
-- - <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
Michael S wrote:
> On Oct 4, 9:50 pm, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>> Anyway, it takes around 30 clock cycles to convert a 32-bit unsigned
>> value to 10 decimal digits.
>> If you have a faster SIMD way of doing this, I'm interested!
> Well, not a general case, but application of brute force "add 3"
> algorithm (hopefully, I don't need to post exact code here, you would
> easily figure it out yourself) to 4 27-bit numbers in range
> 0..99,999,999 should deliver 4 BCD results in approximately 270 128-
> bit AVX instructions that should take (on SandyB/IvyB) something like
> 150 clock cycles.
> The number of clocks does not include loading of constants into xmm
> registers that could cost few more cycles in scalar call, but not
> significant when you process long vectors.
> So, your variant still wins, even on throughput.
<BG>
> But AVX2 is coming. With AVX2 it would be possible to process 8
> numbers at time and thus to beat you on throughput by something like
> 25%.
Except that I can easily run 2-4 conversions in parallel when I have 16 64-bit registers available, this would at least double my throughput.
> Now, that's just a direct adaptation of half a century old hardware-
> oriented algorithm to software. I didn't try to think about smarter
> ways.
Bzzt! Wrong answer. :-)
The fun part was to figure out that a sub-10 cycle 32x32->64 MUL guaranteed a _much_ faster conversion than the classic div/mod 10 iteration which takes 40+ cycles per digit.
I use 4 MUL operations, all the rest is LEA/AND/SHR, i.e. fast & simple opcodes.
Terje
-- - <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
>> On 10/2/2012 4:22 AM, Stephen Sprunk wrote:
>>> On 24-Sep-12 08:48, Anonymous wrote:
>>>> It would seem from Intel's other horrific blunders and foolish
>>>> missteps over the past decades they were and are relatively hostile
>>>> to outside influences and they seem to have gone out of their way
>>>> several times to shoot themselves in the foot.
>>> Pretty much _every_ ISA that Intel has ever deliberately designed has
>>> been a miserable failure. Their successes have been either accidents or
>>> a result of copying someone else.
>> Intel has had several major successes.
> I guess we differ on what success means. Certainly Intel is commercially
> successful, but so were Bill Clinton and so is Microsoft.
I think the OP meant commercial success.
> Success doesn't
> mean something is good, it means it's well-marketed. Sadly, successful
> products are often considerably worse than the alternatives.
I agree that there are different measures of success, but commercial success at least has the advantage that it is objectively measurable. But "worse than the alternatives" is based on one personal definition of worse. I can't argue with your definitions of better or worse, but realize that not everyone will agree with it.
> Intel has a knack for designing (or adopting) unnecessarily complex ISAs and
> implementing them in the lamest ways possible. Simple, elegant designs are
> signs of healthy minds. Intel's convoluted horseshit is the product of sick
> people. I've seen enough technology and people who make it to make the
> connection.
I agree that "elegance" is a good thing, but remember, given the technology of the day when the 8080 say was designed, there were severe limitations that caused some of their decisions.
>> The original 8080 arguably started the personal computer revolution,
> IBM arguably started the personal computer revolution.
No, it didn't. Systems like the Altair 8080, and other 8080 and CPM OS systems, as well as the original Apple preceded the IBM PC by several years. I agree that IBM had the biggest commercial success, but we know you discount that as a criterion. :-)
> Given what someone
> else reminded us, that nobody sees the ISA much less the actual hardware,
> they could have powered it with two soup cans and a piece of
> spaghetti. Intel was just lucky to be the soup cans and Microsoft was the
> spaghetti. No offense to Cambpells or Italians intended!
>> obviously the X86
> Very arguably the worst ISA ever "designed"
By some criteria that you don't state and is probably not objectively measurable.
>> and don't forget the 8051, which, by volume, swamps anything else around.
> TI painted a big bullseye on the 8051 and its best days are long gone.
Even if that is true, it doesn't refute the point that it was very widely adopted and was the acknowledged market leader in its segment for many years.
> I
> haven't looked at it but if it's like anything else that ever came out of
> Intel.. again, commercial success is no indication that something is
> actually good or designed properly.
So, without looking at it, you damn it simply because it came from Intel?
>>>> AMD and Intel flubbed the 32 to 64 bit changeover so badly they
>>>> still haven't fixed it and it will probably require changes to ELF
>>>> and various OS to do it correctly, which isn't going to happen
>>>> overnight. Nobody seemed to have a clue on this, and they should have
>>>> seen it coming from the 16 bit to 32 bit changeover but they didn't.
>>> It's far too late to change x86-64 now; that mistake was pretty much set
>>> in stone a decade or so ago.
>>>> Intel's instruction encoding is bizarre and complicated in the
>>>> extreme.
>>> Well, the original ISA made a reasonable amount of sense back when it
>>> was designed, but there really wasn't any way to extend it in a
>>> reasonable way because, AFAICT, that was never a design consideration.
> That's exactly the point. IBM and other manufacturers have been able to
> extend their designs without legacy baggage while still being upward
> compatible.
Oh. How about the problem that the original S/350 and pre XA S/370s had a 24 bit (16 MB) addressing space but allowed free use of the upper byte in their 32 bit word? This caused many problems when the address space was expanded. Or the fact that in the original design, IBM allowed users to see the OS within their address space and many people, customers, independent vendors and IBM itself wrote software that relied on that which limited IBMs ability to change lots of things as time went on, even to this day.
> Intel is incapable of doing this at all. And their embarassing
> blunders affect day-to-day use of modern OS that run on Intel designs.
Others will have to chime in here, but can't you run old DOS programs on the latest Intel or AMD CPUs?
snip
>>>> Given IBM was there first in all cases, and did things seamlessly
>>>> and elegantly (and their tech pubs are freely available online) there
>>>> really isn't any excuse for Intel's consistent history of embarassing
>>>> fuckups.
>> Come on now. First of all, IBM wasn't first, Univac, or arguably ABC
>> was.
> In practice, nothing is left of UNIVAC or anything else.
Oh, do you mean that because they are no longer commercial successes, we shouldn't consider them? :-) BTW, the descendants of the Univac 1108 (Contemporaneous with the S/360) are still being made, sold and supported.
> IBM set the
> standard of doing things right the first time, and actually thinking
> ahead.
You mean like selling a transaction monitor that allowed a user written COBOL transaction with a subscript going awry to write all over another transaction's code or data, or even overwrite the transaction monitor code itself?
You seem to be an IBM fan boy. While I do admire much of what IBM did, I am not blind to their mistakes. And no, I am not an Intel fan boy. They made plenty of their own mistakes.
> Their designs evolved and are still working, and they didn't subject
> their customers to any of the ridiculous hoop-jumping Intel software
> engineers have had to put up with.
>> Second of all, you are conveniently forgetting all of IBM's
>> mistakes. For examples, look at the System/1, the System/7, the System
>> 32/34/36.
> Why are those mistakes? They were all upward compatible
Compatible with what?
> and they all worked
> and sold well (except for S/32 and S/7 which I never head of).
Earlier, you blew off Univac but now say these systems were good because they sold well, even if they are no longer being produced?
>> Even the S/360 architecture has had significant mistakes. For
>> example, others have mentioned the 16 bit floating point.
> It also had 32 and 64 bit floating point. Caveat emptor. Nobody forced you
> to use it.
Only if you wanted to use floating point at all.
> Do you want me to list all the broken, idiotic instructions in
> the Intel ISA? How much time do you have?
I never claimed Intel didn't make any mistakes. It was you who claimed that IBM made none.
> And you're not making a valid
> comparison. System 360 came out in 1964. What do you want to compare it to?
> We're comparing Intel's broken non-designs now, to what else is available
> now. Join the discussion!
I thought we were talking about the evolution of systems and mistakes that made future use harder. If you are comparing the current X86 instruction set to the current IBM System Z instruction set, that is a whole different thing. We can talk about that if you wish.
>> Also, I regard the way the the addressing is set up with over half the
>> available addressing space taken up by the OS and shared memory, and
>> exposing the OS's internal addresses to the user program, thus limiting
>> program size and needing kludgy OS support to get around as a mistake.
> What are you talking about here and to what are you comparing it? Are you
> still back in 1964? Then compare it to a contemporaneous OS...if you can.
OK. Univac's Exec 8 on the 1108 put the OS in its own address space, which user programs couldn't see. The only way for a user program to interact with the OS was by an instruction analogous to SVC.
If you want a current example of an IBM mistake, look at MVS JCL. Clearly, it is a well designed, throughly thought out and easy to use way to deal with an OS :-) Come on!!!
> There are hardware features that protect everything, something Intel has
> never been able to implement. There's no program size limitation and no OS
> kludging.
There's lots of OS kludging. Perhaps you are too close to it to see it. See, for example, Lynn Wheelers posts on the history of cross address space calls.
> If you're talking about OS/360 then compare it to UNIX years
> later. You can't compare it to UNIX in 1964, since OS/360 was around a long
> time before Bell Lab's first UNIX. At least compare apples and apples.
>>>> ... nobody seems to have adopted [IBM's] hardware/software
>>>> as a package philosophy except perhaps to a much less extent Sun with
>>>> Solaris/SPARC, and that was also a very nice platform.
>> All of the other mainframe companies did so. But it takes a huge amount
>> of resources to do both and those companies have been pushed to the
>> fringes of the computing world, or out of it altogether.
> None of the other mainframe companies did so
All of the BUNCH provided both hardware and software. All provided at least one OS and utilities and compilers for major languages then in use. Most provided a database
...
On Oct 5, 1:57 pm, Stephen Fuld <SF...@alumni.cmu.edu.invalid> wrote:
> On 10/5/2012 4:49 AM, Fritz Wuehler wrote:
> > eStephen Fuld <SF...@alumni.cmu.edu.invalid> wrote:
> >> The original 8080 arguably started the personal computer revolution,
> > IBM arguably started the personal computer revolution.
> No, it didn't. Systems like the Altair 8080, and other 8080 and CPM OS
> systems, as well as the original Apple preceded the IBM PC by several
> years. I agree that IBM had the biggest commercial success, but we know
> you discount that as a criterion. :-)
This depends what you mean by "the personal computer revolution".
Certainly magazines started talking about a "personal computer
revolution" by the time of, say, the Commodore PET.
There was a "microcomputer revolution" as far back as the 8008-based
Mark-8 on the cover of Radio-Electronics magazine, even if that didn't
really take off until the Altair 8800 came out.
Then machines which didn't require one to purchase an ASR-33 from a
radio ham in order to have text input and output, like the Commodore
PET, the TRS-80, and the Apple ][, started pundits talking about the
"personal computer revolution".
While these 8-bit machines were used in office environments, the use
of inexpensive microcomputer systems for business purposes took a
significant step forwards when a number of companies made machines
running the CP/M operating system. (Of course, there were other
business-oriented micros, such as the Radio Shack Model II, out there
as well.)
The thing is, though, that the CP/M based machines tended to have
incompatibilities, such as unique disk formats.
So when IBM introduced the IBM Personal Computer on August 12, 1981...
exactly what happened?
It was too expensive for the home market, but for the business market,
it offered capabilities similar to those of CP/M machines, for about
the same price as many of them (less than some of the most solidly
built ones). The most important applications, such as dBase II, were
ported from CP/M to the PC platform.
But while the price was the same, you could put *ten times the memory*
on one of them.
And it was *one standard machine* with *one disk format*, from the
biggest name in the computer industry.
A little later on, when the PC clones came out, IBM PC compatibility
finally came within the reach of the home market. And I could also
mention Windows 3.1, much later, as making a Macintosh-like GUI
environment affordable.
The IBM PC didn't make the microcomputer revolution happen. What it
did do, though, was cut short the infancy of that revolution, in which
numerous platforms competed, with no clear indication of which
computer would be the best investment for the future - and instead
give people confidence that they could move their programs over when
it came time to upgrade, from an 8088 to an 80286 to an 80386 to a
Pentium...
It turned the microcomputer from an expensive toy to a practical
workhorse. That was a revolution in its own right.
On Fri, 05 Oct 2012 17:10:02 +0200, Terje Mathisen <"terje.mathisen at
tmsw.no"> wrote:
>Fritz Wuehler wrote:
>> You're a lot more forgiving than I am. I find these design fuckups
>> inexcusable, and I don't agree they're not "big problems overall". Try
>> living with a pure 32 or 64 bit Linux or UNIX and tell me these aren't real
>> problems. These non-designs make practical day to day use a living hell when
>> you have to have two sets of libraries and separate link and load paths for
>> everything. It's an embarrassment for Intel x86 and the OS that run on
>This has absolutely nothing to do with Intel and the actual x86/x64 cpus >they provide, if Linus had cared about making a 64-bit OS which was >backwards compatible with 32-bit programs, then they could have employed >exactly the same kinds of conversion thunks that IBM used on their >mainframes.
I have to disagree at least partially with that. While you could
allow 32 and 64 bit x86 code to share an address space (at least 4GB
of it), transitions and mixing of 32 and 64 bit code is not nearly as
easy as it is on S/360.
On S/360..zArch, there is only a single ISA, and you can execute an
AGR (64 bit register-to-register add) in any address mode - 24, 31 or
64 bit. Likewise all registers (and all 64 bits of those registers)
are available in all address modes. And the application can
transition between address modes with a single (unprivileged)
instruction (usually a branch, but there's a direct set-mode
instruction as well). On x86, such things would require at least some
help from the OS.
The evolution of the S/360 OS's is/was rather different too. While
there were definitely (major) kernel changes required during the 24-31
and 31-64 bit transitions, the actual evolution of the OSs was much
slower. At first many system services remained callable only in the
older mode, and the OS support for the longer addressing modes
increased over time. But early applications that needed to make use
of the larger addressing modes could do so, but needed to build in
their own thunking to get to system services (and other subsystems)
that didn't support the newer mode yet. And some of that evolution
has been pretty slow - there are still a few control blocks
(structures) that need to be allocated in 24 bit storage (some 29
years after the first 31 bit models shipped), and many services are
still not available in 64 bit mode (even the ability to put code, as
opposed to data, above the 2GB line is severely restricted in zOS).
Contrast that with 32 or 64 bit Linux or Windows, where the OS is
basically one mode or the other, but with a thunking layer for 32 bit
code.
In a sense IBM was forced into that approach since a big-bang
conversion of something like MVS would have been impossible.
