Page 3 of 3 FirstFirst 123
Results 21 to 27 of 27

Thread: AMD To Open-Source Its Linux Execution & Compilation Stack

  1. #21
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    906

    Default

    Thanks!

    Still, information seems a bit scattered all over the place.

  2. #22
    Join Date
    Sep 2006
    Posts
    714

    Default

    Quote Originally Posted by rrohbeck View Post
    Now if they could explain what they plan in a way that a simple computer scientist like myself understands what they're going to do...
    GPGPU + CPU + Possibly other stuff == New multicore computer architecture.

    So AMD is releasing software that will help people develop compilers and libraries to take advantage of it.

  3. #23
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Quote Originally Posted by entropy View Post
    Thanks! Still, information seems a bit scattered all over the place.
    We post info to the xorg wiki first then update amd.com later. Looks like we need another sync there.

    The 3D programming docco on the xorg wiki covers from 6xx through NI pretty well since they all use the same core architecture. It wouldn't hurt to add delta docs for things like attribute interpolation in the shaders, although the ISA docs and driver code also cover the changes. SI needs an all new docco set and that should probably be highest priority.

  4. #24
    Join Date
    Apr 2011
    Posts
    309

    Default

    Well CISC is not RISC and does not decode anything in RISC (that is recompiling), decoding is another thing. RISC means relative instructions (one is little the other, or, continuation of another), CISC is the opposite (complex relations between instructions). CISC cannot execute directly many instructions, so executes them in Micro-Ops (frames in space or in time), its the only way for a CISC because 20-30 different units is not possible, instead 7 units are good wille RISC can have only 1 (vector registers). Micro-Ops are not RISC because are not relative and are not instructions. RISC is 20 times smaller for the same general processing power and 40 times smaller for stream processing like gaming, and thats because you cant find any game with static compiled graphics in order to use the complexity.

  5. #25
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    906

    Default

    Quote Originally Posted by bridgman View Post
    We post info to the xorg wiki first then update amd.com later. Looks like we need another sync there.

    The 3D programming docco on the xorg wiki covers from 6xx through NI pretty well since they all use the same core architecture. It wouldn't hurt to add delta docs for things like attribute interpolation in the shaders, although the ISA docs and driver code also cover the changes. SI needs an all new docco set and that should probably be highest priority.
    A sync would be nice but as I see now it's all properly linked at
    http://www.x.org/wiki/RadeonFeature#Documentation

    My bad!

  6. #26
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Whoops, my bad too... I completely forgot about that. We actually had docco in a third place -- the Stream (now APP) SDK web pages, so agd5f built a list to wrap them all. Apologies if it was someone else than agd5f

  7. #27
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote Originally Posted by ldesnogu View Post
    They probably used what is considered in the industry as the best C++ front-end: Edison Design Group C++. It's used by almost all larger companies that produce their own compilers (TI, Intel to name a few).
    Note that this opinion has not been re-evaluated in recent years. That is, everyone uses EDG because everyone uses EDG and there weren't any alternatives (GCC's frontend is not only GPL'd, it's also a ****ing nightmare to integrate into anything else, GPL'd or not). Clang has sprung into existence just a few years ago and is already at the same level of C++11 support as GCC. One can expect that in the coming years, a lot of tools may well migrate from EDG to Clang. The ones that don't will mostly be those monstrous clunking behemoths for which replacing the frontend would be far too much work, or those that have invested too heavily in modifying the EDG-based frontend (like Microsoft's compiler, which lags in C++11 because it's essentially a fork of an ancient version of EDG, but all of the crazy Microsoft extensions like C++/CLi and C++/Cx only exist in that frontend).

Posting Permissions

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