Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Programming Hardware Technology

The Legacy of CPU Features Since 1980s 180

jones_supa writes: David Albert asked the following question:

"My mental model of CPUs is stuck in the 1980s: basically boxes that do arithmetic, logic, bit twiddling and shifting, and loading and storing things in memory. I'm vaguely aware of various newer developments like vector instructions (SIMD) and the idea that newer CPUs have support for virtualization (though I have no idea what that means in practice). What cool developments have I been missing? "

An article by Dan Luu answers this question and provides a good overview of various cool tricks modern CPUs can perform. The slightly older presentation Compiler++ by Jim Radigan also gives some insight on how C++ translates to modern instruction sets.
This discussion has been archived. No new comments can be posted.

The Legacy of CPU Features Since 1980s

Comments Filter:
  • by Eunuchswear ( 210685 ) on Wednesday January 14, 2015 @09:55AM (#48810873) Journal

    The first large scale availability of virtualisation was with the IBM 370 series, dating from June 30, 1970, but it had been available on some other machines in the 1960's.

    So the idea that "newer machines have support for virtualisation" is a bit old.

    • Yeah.

      Also, vector processors [wikipedia.org] are also from the 70's as well.

    • by sirwired ( 27582 ) on Wednesday January 14, 2015 @10:25AM (#48811093)

      I remember when VMWare first came out, and there was all this amazement about all the cool things you could do with Virtual Machines. Very little mention anywhere that these were things you could do for decades already on mainframes.

      Same thing with I/O offloading (compared to mainframes, x86 and UNIX I/O offload is still quite primitive and rudimentary), DB-based filesystems (MS has been trying to ship one of those for over 20 years now; IBM has been successfully selling one (the AS/400 / iSeries) for 25, built-in encryption features, and a host of other features.

      • by dpilot ( 134227 )

        I remember when the 8086 came out, Intel also brought out the 8087 FPU and the 8089 I/O Processor. The former got bundled into the CPU a few generations later. I don't rememeber details of the 8089, but it seems to have withered away. Nor does Wikipedia say much about it, once you differentiate it from the Hoth Wampa Cave Lego set.

      • Aside from the 'ignorance' and 'marketing' effects, it's arguably a testament to the fact that people will forgive a great many sins if the price is right.

        Even considering VMware's periodic moves into 'We still have the x86 virtualization market by the balls, right?' pricing models, being able to do virtualization on practically disposable Dell pizzaboxes looks like a revelation if you've previously been enjoying the pleasure of juggling your PVUs, subcapacity licenses, capped and uncapped LPARs, and sim
        • by tibit ( 1762298 )

          Not only do their prices sting, but they suffer heavily from living on their own little island and steadfastly refuse to use standard terminology, and seem to be doing a lot of stuff differently just because they can - not because it makes sense.

      • Re: (Score:2, Interesting)

        by Anonymous Coward

        In the before time, in the long, long ago, Quarterdeck first offered DESQView. I built VMs operating Index BBS on i286 platforms using digiboards.

        Sweet Jesus little has changed in >25 years.

      • by AmiMoJo ( 196126 ) *

        People were aware that mainframes could do virtualization back then, not least because all the magazine articles about VMWare mentioned it. What was surprising was that a feature previously only available on room sized computers costing as much as your lifetime earnings was now available on cheap commodity hardware.

      • by Richard_at_work ( 517087 ) on Wednesday January 14, 2015 @11:45AM (#48811827)

        Bugger me, when I first got hold of VMWare as a teenager then heavily into Linux, I went mad. And I mean maaaaaaaaaaaaaaaaaad.

        My home server was a simple affair - 6GB hard disk, 512MB ram.

        So what did I do? Bring up as many Redhat VMs as I could - all with 4MB ram :D It was like a drug, 10 wasn't enough, so I did more. I got to 50 and just knew I had to do 100. I eventually ran out of free ram, but hell, I had more than 100 servers at my disposal!

        What did I do with them? Uhm, nothing. Apart from sshing into a few just because I could.

        *sigh* Thems were the days....

        • Comment removed based on user account deletion
        • Should have set up a random interlink between each one and fired up an AI script and hope it acted like neurons.
      • when VMWare first came out, and there was all this amazement about all the cool things you could do with Virtual Machines. Very little mention anywhere that these were things you could do for decades already on mainframes.

        This is probably due to the fact that for most values of "you," you don't have a mainframe. So the cool things switched from "things a-few-people-who-aren't-me can do" to "things I can do." That increases relevance.

    • A nontrivial amount of 'progress' in hardware is really a story of the toy microcontrollers running DOS (that mortals could actually afford) gradually reinventing or acquiring features old enough to have owned hideous polyester disco suits; but historically only available on IBM systems that leased for the GDP of a small nation state...
      • but historically only available on IBM systems that leased for the GDP of a small nation state...

        Apart from virtualisation not much has been pioneered by IBM.

        And we used to joke back in the day that the reason IBM were so keen on virtualisation was that they couldn't write a multi-user operating system, so they worked out how to let each user run his own copy of a single user operating system.

        • by bws111 ( 1216812 )

          Riiight. Other than minor little things like:

          System architecture being independant of machine implementation
          8 bit bytes
          32 bit words
          Byte addressable memory
          Standard IO connections

          And that is just stuff from the 360 family, 50 years ago.

        • It's a bit before my time, but I believe OS/VM was not originally an IBM product, but was from people in the User Group. There was a Free Software/Open Source culture back then, and then as now anybody who had a computer could participate. This included hacks to the OS itself, like HASP, which would read a whole card deck at a time and put it on disk, rather than the program reading cards from the reader each time it wanted more input.

          • by bws111 ( 1216812 )

            There is no OS/VM. VM-370 came from CP-67, which was an IBM project. No doubt many users contributed later, but the origins were IBM.

            HASP was an extension to OS/360 (z/OS predecessor) and has nothing to do with VM.

    • The first large scale availability of virtualisation was with the IBM 370 series, dating from June 30, 1970, but it had been available on some other machines in the 1960's.

      So the idea that "newer machines have support for virtualisation" is a bit old.

      This point has been made since the first virtualization software on microcomputers were being experimented with. Those who don't know history are doomed to repeat it (or something similar depending how diligent your citation tracking it).

      I'm still waiting for someone tell us that IBM discovered perceptional acceptable lossy compression, such as JPEG, MP3, and MPEG, back in the mid-1960s mainframe era to generate image and videos for punchcards distribution.

      And Xerox PARC labs had a portable MP3 player prot

    • by sjames ( 1099 )

      Yes, but he is clearly writing for people who grew up professionally with the x86.

      In the PC world, efficient virtualization is a new thing even though mainframes had it long ago.

      • Yes, but he is clearly writing for people who grew up professionally with the x86.

        There was never an 8-bit x86, and that includes the 8088.

        • by sjames ( 1099 )

          The 8088 had an 8 bit external bus. Meanwhile, the z80 could do 16 bit fetches in a manner quite similar to the way an 8088 did a 16 bit fetch. Either way, 1 memory cycle got you 8 bits, so which is 8 bit and which is 16?

          • The 8088 had an 8 bit external bus

            ..which has nothing to do with being 8-bit...

            bus width
            address lines
            fastest word size

            Which one of these has never been used to define the bitness of a machine? Yes, its the one you are using.

            Anyone with a triple channel i7 has a 192-bit desktop right now (thats the width of the data bus of first gen i7's) according to your idea of what machines a machine 8-bit...

            no IBM PC was ever 8-bit.. never.. they started with a 16-bit word size and 20-bit addresses.. some might argue they were 20-bit, but it

            • by sjames ( 1099 )

              Now go upstairs and change your pants.

              You also apparently don't know how multiple memory channels work. Hint: it's separate busses, that's where the speed comes from.

              • Your defense of your claim that the 8086/8088 were 8-bit processors has come to this.

                I'd get off your lawn but its only artificial turf.... some dork that signed up to slashdot really early but never actually did shit...
  • by PhrostyMcByte ( 589271 ) <phrosty@gmail.com> on Wednesday January 14, 2015 @10:10AM (#48810977) Homepage

    The latest generation of CPUs have instructions to support transactional memory.

    Near future CPUs will have a SIMD instruction set taken right out of GPUs where you can conditionally execute without branching.

    • A lot of systems are going with a traditional general purpose CPU for the control system, but DSP CPUs for the hard core or time critical calculations. DSPs already have a lot of SIMD features.

      What's interesting is that DSPs are also adding more and more general purpose capabilities.

  • Cooking (Score:5, Funny)

    by morgauxo ( 974071 ) on Wednesday January 14, 2015 @10:17AM (#48811045)

    There was a period in the 0s when PC processors were good for cooking eggs. You had to be careful with the AMD ones though, they had a tendency to burn the egg quickly.

    • I would imagine that the prizes for that would go to the Itanium and the Alpha. I've always thought it would be neat if one could establish a cluster farm in the open in the North Pole of Cold in Siberia, where the CPUs could be laid out w/o heat sinks and overclocked. It could be a good way of warming the air, while also providing fantastic supercomputing facilities. Of course, they'd have to be laid out in ways that they always face a wind chill of -40.

      Of course, one is more likely to get something o

      • I've never worked with Itanium or Alpha, but on PCs the Pentium 4 was the undisputed King of Watts. Power usage on it got rather silly. You see that odd little four-pin power cable you going to the mainboard in addition to the main power bundle? That's the supplimentary power supply introduced to feed the insatable demands of the P4.

      • by sjames ( 1099 )

        Not quite that, but there is a supercomputing center in Alaska to take advantage of easy cooling.

    • Re: (Score:2, Funny)

      by Anonymous Coward

      Since then, we have offloaded that task to the graphics card, thereby freeing up the main CPU for hash browns.

    • Re:Cooking (Score:5, Informative)

      by jellomizer ( 103300 ) on Wednesday January 14, 2015 @11:47AM (#48811851)

      That was during the Mega/Gigahertz war, during the Golden Age of the Desktop.

      Power Usage wasn't an issue. Heating wasn't much of an issue as you can fit big honking liquid cooled heat sinks to your CPUs. We had these big upgradable towers which gave us room to fill with stuff.

      So we had hotter CPU's because we wanted the faster clock speed.

      What happened? Well first 3ghz kinda became the max you can go, and we moved to more parallel systems. (Multi-Core CPU's, and GPU), and we wanted more portable devices. Laptops became far more popular then smartphone and tablets. So power usages, size, and heat became a bigger issue.

    • by AmiMoJo ( 196126 ) *

      Shirley you mean Intel. Around 2000 the Pentium 4 silliness was in full swing. Super long execution pipeline, totally reliant on high clock speeds for performance. Those things could burn the Intel logo into your toast in under 5 seconds.

  • by DahGhostfacedFiddlah ( 470393 ) on Wednesday January 14, 2015 @11:00AM (#48811405)

    We just had a story about low-level improvements to the BSD kernel, and now we get an article about chip-level features and how compilers use them?

    Is this some sort of pre-April-Fools /. in 2000 joke? Where are my Slashvertisements for gadgets I'll never hear about again? My uninformed blog posts declaring this the "year of Functional Declarative Inverted Programming in YAFadL"? Where the hell are my 3000-word /. editor opinions on the latest movie?

    If this keeps up, this site might start soaking up some of my time instead of simply being a place I check due to old habits.

    • by tepples ( 727027 ) <tepplesNO@SPAMgmail.com> on Wednesday January 14, 2015 @11:09AM (#48811515) Homepage Journal

      If you want to see more Slashdot-in-2000 style posts, and you have access to the sort of articles that Slashdot-in-2000 might have posted, Slashdot welcomes your submissions. You could even become a "frequent contributor".

      • If you want to see more Slashdot-in-2000 style posts, and you have access to the sort of articles that Slashdot-in-2000 might have posted, Slashdot welcomes your submissions. You could even become a "frequent contributor".

        Um, no. This used to be the case, but the only stories I've submitted that have actually been picked by the editors in the last 5 years have been the "look at this new tech", "look at this glaring mistake" or the political kind. Anything about explaining actual existing tech or showing novel new uses for existing tech has never made it past the editors.

        These days it's extremely easy to become a "frequent submitter" without becoming a contributor at all -- even when you do your own editing, have a reasonab

        • by jones_supa ( 887896 ) on Wednesday January 14, 2015 @01:47PM (#48812961)
          As the submitted of this article, I recommend you to continue chucking in the articles that you find interesting. You seem to have 17 articles submitted, of which 6 have been published, which is pretty good actually. There's many factors that decide whether your submission gets the front page or not, so there's no need to be too personal about it. I personally keep submitting articles just for fun. Most of my topics come from Twitter these days, it's a good source to pick up interesting stuff.
          • by antdude ( 79039 )

            I used to be one/1 of the top /. submitters until it changed. I rarely submit to /. these days, but do on other web sites like Reddit [reddit.com], Blue's News [bluesnews.com], etc. :)

  • I have had arguments over this. People in various fora have asked what programming languages they should learn. I always put assembly in my list. But is it really important enough to learn these days? Is hardware still relevant?

    • If you want to get the most out of an 8-bit microcontroller, you'll need assembly language. Until recently, MCU programming wasn't easily accessible to the general public, but Arduino kits changed this.

      • by itzly ( 3699663 )

        If you want to get the most out of an 8-bit microcontroller, you'll need assembly language

        Or you just throw your 8-bitter in the garbage, and grab one of the many ARM MCUs out there.

    • by Chirs ( 87576 ) on Wednesday January 14, 2015 @11:14AM (#48811563)

      For example, I worked for a decade in the linux kernel and low-level userspace. Assembly definitely needed. I tracked down and fixed a bug in the glibc locking code, and you'd better believe assembly was required for that one. During that time I dealt with assembly for ARM, MIPS, powerpc, and x86, with both 32 and 64-bit flavours of most of those. But even there most of the time you're working in C, with as little as possible in assembly.

      If you're working in the kernel or in really high-performance code then assembly can be useful. If you're working with experimental languages/compilers where the compilers might be flaky, then assembly can be useful. If you're working in Java/PHP/Python/Ruby/C# etc. then assembly is probably not all that useful.

    • by Shinobi ( 19308 )

      Hardware should always be a concern, because hardware is the reality that implements the abstraction of a program. No matter how efficient something is in purely mathematical terms, it's the hardware that determines the actual performance, complexity and problems. ISA, I/O capabilities, amount of RAM etc all matter in deciding what will be the best way to implement something.

      No matter how many layers of abstraction you put in to provide the illusion of being able to ignore the hardware, the reality of hardw

    • by Bengie ( 1121981 )
      You don't need to actually program in ASM to gain benefits, just looking simple code and reading what it does gains you much insight. Very few problems of CPU bound, but many problems are cache or memory access bound. Data-compactness and memory access patterns are still very important.

      There are also other problems that really play into multi-threading, where reducing the number of dirty cache-lines you need to access is important, which means understanding memory alignment and many other things.
    • There are only two situations I can think of where a working knowledge of assembly would be useful:
      1. You write compilers.
      2. You work in embedded device programing, where some IO requires you to count instruction cycles to ensure correct timing.

      • by itzly ( 3699663 )

        Or you need to do stuff that requires special instructions, like enabling/disabling interrupts, or magic co-processor instructions that flush the cache. Of course, if you're lucky, somebody made C wrappers for them, but that's not always the case.

        • Keep in mind that the fastest implementations of just about any ultra-common standardized algorithms ((un)encryption, (de)compression, etc...) are in assembler. This fact doesnt shed as good light on compilers as some people like to disingenuously shine. Sure, most of the time you don't care that much about every last bit of performance, but when the CPU time for the algorithm in question easily totals billions of CPU hours... suddenly the arguments about assembler not being important start to look rather f
    • It's not just that assembly language isn't as used any more, as that the machine language on the current processors is much more of a mess than the other ones I learned and used a long time ago. If there was something like the old Motorola 6809, that would be great to learn on.

  • I haven't seen the article or video. But for 99% of developers, I'd say the only CPU-level changes since the 8086 that matter are caches, support for threading and SIMD, and the rise of external GPUs.

    Out-of-order scheduling, branch prediction, VM infrastructure like TLBs, and even multiple cores don't alter the programmer's API significantly. (To the developer/compiler, multicore primitives appear no different than a threading library. The CPU still guarantees microinstruction execution order.)

    Some of th

    • And of course, ever since the 80486 (1989), all CPUs support floating point instructions.

      486 SX chips had the FPU disabled or absent. So not all CPUs (or even all 80486 CPUs). As far as I'm aware Penitum (586) did not have a model without FPU support (although in the MMX models, you couldn't use MMX and the FPU at the same time).

      • Also note that rather recently Intel drastically dropped the accuracy of their FPU's in order to make the performance numbers look better.... dont expect 80-bit procession even when explicitly using the x87 instructions now... its now been documented that this is the case but for a few years Intel got away without publicly acknowledging the large drop in accuracy....
  • I'm not a CPU expert so feel free to take my opinions below with a grain of salt... (grin)

    The biggest change to processors in general is the increased use and power of desktop GPUs to offload processing-intense math operations. The parallel processing power of GPUs outstrips today's CPUs. I'm sure that we will be seeing desktop CPUs with increased GPU like parallel processing capabilities in the future.

    http://en.wikipedia.org/wiki/G... [wikipedia.org]
    http://www.pcworld.com/article... [pcworld.com]

    • indeed, the architecture of stream processors is quite a bit different than the general purpose processors we are used to programming. It's kind of exciting that programming stream processors through shaders, openCL, and CUDA has gone mainstream. And for a few hundred dollars a poor college student can afford to build a small system capable of running highly parallel programs. While not equivalent in performance to a super computer, has structural similarities sufficient for experimentation and learning.

      20

  • I'm not sure SIMD really falls outside of a "1980s" model of a CPU. Maybe if your model means Z80/6502/6809/68K/80[1234]86/etc, rather than including things like Cray that at least some students and engineers during the 80s would have been exposed to.

    von Neumann execution, but Harvard cache become common place in the 1990s. Most people didn't need to know much about the Harvard-ness unless they need to do micro-optimization.

    Things don't get radically different until you start thinking about Dataflow archit

    • TFA's second line indicates that everything in the article refers to the x86/64 architecture. It is true many of these features originate in much older archs, but they are being introduced into the x86/64 arch over time.

      • Sorry if you missed it, but my post tried to point out that x86/64 is not really different from "1980s" CPU architecture. It's an 8085 with harvard cache, out-of-order execution and RISC translation instead of microcoded (not that that is a significant difference in my opinion)

        x86 will eventually get transactional memory, making it competitive with a 1970s cray. And x86 has gotten hardware visualization, making it competitive to an 1960s IBM.

        Everything old is new again!


  • while (hitCount < arraySize) {
    i=rand() % arraySize;
    if (hitArray[i] == 0) {
    sum += array[i];
    array[i]=0;
    hitArray[i]=1;
    hitCount++;
    }
    }

  • I used to sort of understand how a computer works. Not anymore. It's just magic.

  • Guy who doesn't understand how CPUs work amazed about how CPUs work. /thread

    • Guy who used to understand CPUs is amazed at how they've changed.

      • Guy who used to understand CPUs is amazed at how they've changed.

        Ya, but, as several posters have pointed out, many of the things you mentioned, like vector instructions and virtualization *have* been around since the 1980s (and/or earlier) -- heck, I was a sysadmin at the NASA Langley Research Center in the mid-80s and worked on a Cray-2 (a vector processor system) and an Intel system with 1024 processors.

        So either your CPU experience is *really* old or perhaps your CPU experience is more limited than you think rather than they have changed to the extent you think.

  • Can someone explain why in the example race condition code given, the theoretical minimum count is 2, and not n_iters?.
    • by Vairon ( 17314 )

      I believe this is a scenario that could cause two threads performing a incl instruction without lock added to overwrite the same memory address in such a way that the end result would be 2.

      thread 1, iteration 0 of 9999: load 0 from memory

      thread 2, iteration 0 of 9999: load 0 from memory
      thread 2, iteration 0 of 9999: add 1 to 0 = 1
      thread 2, iteration 0 of 9999: save 1 to memory

      ...thread 2 iterates multiple times...
      thread 2, iteration 9998 of 9999: load 9998 from memory
      thread 2, iteration 9998 of 9999: add 1

  • by bmajik ( 96670 ) <matt@mattevans.org> on Wednesday January 14, 2015 @04:00PM (#48814105) Homepage Journal

    if you understand scalar assembly, understanding the basic "how" of vector/SIMD programming is conceptually similar

    Actually, if you think back to pre-32bit x86 assembler, where the X registers (AX, BX) were actually addressable as half-registers (AH and AL were the high and low sections of AX), you already understand, to some extent, SIMD

    SIMD just generalizes the idea that a register is very big (e.g. 512 bits), and the same operation is done in parallel to subregions of the register.

    So, for instance, if you have a 512 bit vector register and you want to treat it like 64 separate 8 bit values, you could write code like follows:

    C = A + B

    If C, A, and B are all 512 bit registers, partitioned into 64 8 bit values, logically, the above vector/SIMD code does the below scalar code:

    for (i == 1..64) {
        c[i] = a[i] + b[i]
    }

    If the particular processor you are executing on has 64 parallel 8-bit adders, then the vector code

    C = A + B

    Can run as one internal operation, utilizing all 64 adder units in parallel.

    That's much better than the scalar version above - a loop that executes 64 passes..

    A vector machine could actually be implemented with only 32 adders, and could take 2 internal ops to implement a 64 element vector add... that's still a 32x speedup compared to the scalar, looping version.

    The Cray 1 was an amazing machine. It ran at 80mhz in 1976

    http://en.wikipedia.org/wiki/C... [wikipedia.org]

    According to WP, the only patent on the Cray 1 was for its cooling system...

If you didn't have to work so hard, you'd have more time to be depressed.

Working...