Image Map Image Map
Page 6 of 7 FirstFirst ... 234567 LastLast
Results 51 to 60 of 68

Thread: FPGA accelerator cards

  1. #51
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,467
    Blog Entries
    18

    Default

    Well, VLIW had some promise for do-it-yourself instructions. Or customer-supplied microcode.

    Maybe we're all doomed to differing architectural "tweaks". X86 probably is the best of all possible worlds.

    Even with old big-iron mainframes, there were differences between models of the same family.

    Maybe it's unavoidable and just a human tendency--after all natural (human) languages keep shifting in meaning. The Tower of Babel phenomenon.

  2. #52

    Default

    Quote Originally Posted by Chuck(G) View Post
    My surprise over Svenska's comment was that the first general-purpose RISC-V MCU hasn't been out all that long. On the other hand, I can see that the lack of IP licensing requirements would be a potent driver for Chinese adoption, which does indeed seem to be the case.
    Well, any company able to design and fabricate chips should be able to integrate a RISC-V core instead of an ARM one. The same is true for softcore designs in FPGAs. Both toolchain support and HDL implementations have been around for quite a while now; some of them are silicon-proven or formally verified and are free to use in commercial designs. That makes them attractive, especially if the rest of the system already exists.

    Quote Originally Posted by Chuck(G) View Post
    And yet, I can see lots of mutually-incompatible RISC-V cores flooding the market.
    On the CPU core level, I don't see that coming yet - RISC-V is well specified and you can't break compatibility without losing the "RISC-V" (in contrast to e.g. MIPS). I do expect wildly incompatible SoC implementations though, but that is not different from any other architecture.

    Quote Originally Posted by Al Kossow View Post
    People will be longing for the days of PC forced compatibility.
    Why should they? "PC compatibility" ceased being relevant more than two decades ago. There is no useful chipset-level compatibility, and interface-level compatibility (BIOS) is emulation anyway, if it is enabled in the first place.

    Quote Originally Posted by commodorejohn View Post
    And if alternative RISC ever finally takes off in the personal-computer market, it'll have to standardize (or at least abstract such features out at the OS level) in order to even be able to have a standard platform in the first place
    Exactly that is how things are currently done: There are Linux compatibility (for servers), Android compatibility (for mobile; quite different from Linux), a multitude of RTOS systems (for smaller systems) and Arduino (which is bare-metal or hosted on top of an RTOS).

    Quote Originally Posted by Eudimorphodon View Post
    The instruction set wasn't the problem there, it was the selection and arrangement of integrated peripheral support features that blew it. Flash-forward to today and I'm pretty sure there are x86 SoCs that definitively break compatibility with any real-mode operating systems but can still run Windows (or Linux, or whatever) so arguably we've already mostly divorced the software platforms from requiring *that* level of hardware compatibility.
    Wasn't it AMD breaking the VME in the first place? I also dimly remember that 16-bit Windows fails to run natively on virtually any modern system in Enhanced Mode. I haven't tried this, since I don't see the point (emulating is more useful).

    Quote Originally Posted by commodorejohn View Post
    True dat - just look at the pile of different ARM builds for various sub-architectures in any given *nix.
    Which is becoming a thing of the past, since with ARMv7 (and ARMv8 ), the various ARM instruction sets have finally converged to the point where the OS kernel can handle the important differences itself. There is no need for special builds and the performance cost is negligible. Userspace applications don't need to care either unless they want to, so most of these problems are finally gone.

    Quote Originally Posted by commodorejohn View Post
    Really makes me wonder if some kind of universal virtual-machine binary translated and optimized by a dedicated OS component (or, ideally, intelligently optimized by the developer and packed into a Mac-style "fat binary") isn't a viable future direction - didn't the AS/400 line do something like this, later on in life?
    Take a look at Android. Basically, all Android apps are Dalvik bytecode (not Java bytecode), which was first emulated and later (Android 2.2) ran through a JIT compiler. Since Android 5.0, this bytecode is actually fully (re)compiled at installation time (apps are also adapted based on other parameters such as memory size and display resolution). Therefore, Android apps are completely architecture-agnostic (unless they contain native code without a fallback), as is most of Android itself.

    Android is an interesting beast, even though I don't like the ecosystem around it.

  3. #53

    Default

    Quote Originally Posted by Svenska View Post
    Take a look at Android. Basically, all Android apps are Dalvik bytecode (not Java bytecode), which was first emulated and later (Android 2.2) ran through a JIT compiler. Since Android 5.0, this bytecode is actually fully (re)compiled at installation time (apps are also adapted based on other parameters such as memory size and display resolution). Therefore, Android apps are completely architecture-agnostic (unless they contain native code without a fallback), as is most of Android itself.

    Android is an interesting beast, even though I don't like the ecosystem around it.
    Interesting. But yeah, it'd be nice if that tech was harnessed to something useful and not owned by a vaguely sinister corporate giant (though at least it's open-source.)
    Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
    Synthesizers: Roland JX-10/SH-09/MT-32/D-50, Yamaha DX7-II/V50/TX7/TG33/FB-01, Korg MS-20 Mini/ARP Odyssey/DW-8000/X5DR, Ensoniq SQ-80, E-mu Proteus/2, Moog Satellite, Oberheim SEM
    "'Legacy code' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup

  4. #54

    Default

    Quote Originally Posted by Chuck(G) View Post
    Maybe we're all doomed to differing architectural "tweaks". X86 probably is the best of all possible worlds.
    Which one? The one with MMX, MMX2 , SSE, SSE2? Maybe I'm just a little irked that I can't run modern browsers (Chrome/Mozilla) on my non-SSE2 machine

  5. #55
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,533

    Default

    If you listen carefully you can still hear the echos of the nerd-range that erupted in 2012 when the mainline Linux kernel cut off support for the original 80386 CPU.

  6. #56
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,467
    Blog Entries
    18

    Default

    Most current Linux 32-bit distros will no longer install on AMD K6 hardware or older.

  7. #57
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,533

    Default

    Support for CPUs as old as the 486 is still technically in the Linux kernel and you can, with sufficient hassle, scrape up or build a working distribution but, yep, mainline distributions are all "686" or higher these days. The stated reason for shooting the 386 in the head in 3.7 was supporting it supposedly requires some annoying special cases that affect the SMP code base, even if they just support single-cpu configurations. I believe the various BSDs have also all dropped the 80386 for similar reasons.

    An annoying thing that happened around the same time the kernel dumped 386 support is a lot of distributions which already wanted Pentium Pro or better started using PAE in the default kernel. This shouldn't have been a huge deal since most post-Pentium Pro CPUs support it, but Intel neglected to include "PAE" in the cpuflags output for a few CPU models. (IE, PAE was actually present but the CPU didn't say it was.) Until the installers started including automatic detection of this issue getting a "Banias" Pentium/Celeron M laptop running involved some swearing.

  8. #58
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,467
    Blog Entries
    18

    Default

    On a K6 or earlier, the installer aborts with a message about the CMOV instruction not being supported. I don't know how essential this is to current 32-bit Linux kernels, but probably can be recompiled without the instruction.

  9. #59
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,533

    Default

    Quote Originally Posted by Chuck(G) View Post
    On a K6 or earlier, the installer aborts with a message about the CMOV instruction not being supported. I don't know how essential this is to current 32-bit Linux kernels, but probably can be recompiled without the instruction.
    Checking the latest stable kernel source (5.3.6) these are all still valid options:

    config M486
    bool "486"
    depends on X86_32
    ---help---
    Select this for an 486-class CPU such as AMD/Cyrix/IBM/Intel
    486DX/DX2/DX4 or SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or U5S.

    config M586
    bool "586/K5/5x86/6x86/6x86MX"
    depends on X86_32
    ---help---
    Select this for an 586 or 686 series processor such as the AMD K5,
    the Cyrix 5x86, 6x86 and 6x86MX. This choice does not
    assume the RDTSC (Read Time Stamp Counter) instruction.

    config M586TSC
    bool "Pentium-Classic"
    depends on X86_32
    ---help---
    Select this for a Pentium Classic processor with the RDTSC (Read
    Time Stamp Counter) instruction for benchmarking.

    config M586MMX
    bool "Pentium-MMX"
    depends on X86_32
    ---help---
    Select this for a Pentium with the MMX graphics/multimedia
    extended instructions.
    I think Slackware is still compiled for 486 in the default distribution; it looks like its last release was three years ago, so I'm not sure if it still counts as "alive", but they were always an outlier in that area as other distributions moved to M586 and M686.

  10. #60

    Default

    Quote Originally Posted by Eudimorphodon View Post
    Checking the latest stable kernel source (5.3.6) these are all still valid options:



    I think Slackware is still compiled for 486 in the default distribution; it looks like its last release was three years ago, so I'm not sure if it still counts as "alive", but they were always an outlier in that area as other distributions moved to M586 and M686.
    It's active to this date:
    http://www.slackware.com/changelog/current.php?cpu=i386
    http://www.slackware.com/changelog/stable.php?cpu=i386

    I don't think the slackware dev is considering i486 supported at this point, if you review current and 14.2 changelogs, he doesn't compile it with i486 optimizations anymore either, even though there isn't a whole lot different between 486<->586 in the ISA. And the current browsers don't work on pure i686 or first gen amd64 either (need SSE2). So any desktop distro that gets on the net really has this issue, that they aren't all that useful on old machines. I think you have memory hog browsers pushing X86 into an unwarranted obsolescence.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •