[HN Gopher] RISE: Accelerate the development of open source soft...
___________________________________________________________________
RISE: Accelerate the development of open source software for RISC-V
Author : luhenry
Score : 65 points
Date : 2023-05-31 16:22 UTC (6 hours ago)
(HTM) web link (linuxfoundation.eu)
(TXT) w3m dump (linuxfoundation.eu)
| Havoc wrote:
| I'm quite optimistic about RISC-V.
|
| It seems to have made the jump from nothing to rasp3B class
| hardware very fast so wouldn't be surprised if it overtakes all
| the other SBC gear soon
| rwmj wrote:
| There are at least 3 companies working on very high end server-
| class chips which I expect will be available in a year or two.
| realjhol wrote:
| I wish someone would make laptop class chips. Not chromebook.
| I want a RiscV power laptop like an M2 mac.
| blacksmith_tb wrote:
| Probably won't be too fast, but now there's an RPi 3-shaped
| RISC-V SBC coming soon[1] you should theoretically be able
| to use a kit like the CrowPi 2[2] to build a laptop out of
| one, potentially.
|
| 1: https://milkv.io/mars
|
| 2: https://www.crowpi.cc/collections/crowpi/products/crowpi
| 2-al...
| sylware wrote:
| We will need legacy software risc-v support for the transition
| towards the real thing: assembly.
|
| Just need to avoid the mistakes from the past: no absurd assembly
| code generators and no grotesque usage of a macro-preprocessor.
| inconceivable wrote:
| i hear compilers are pretty good at generating assembly these
| days.
| yjftsjthsd-h wrote:
| I'm slightly out of the loop, but don't modern compilers
| often actually skip real assembly and go from source code to
| an intermediate representation (which is _like_ asm but not
| quite the same) to binary? Or is that aside your point?
| sylware wrote:
| You can have a look at cproc + qbe (I tend to favor that
| instead of tinycc, ofc clang and gcc are pure evil).
| inconceivable wrote:
| asm can be the input and/or the output.
|
| https://stackoverflow.com/questions/10990018/how-to-
| generate...
| snvzz wrote:
| I recommend reading the forward[0] of The Art of Assembly.
|
| Or to just look at the output of your favorite compiler.
| Nobody has ever looked at the output of a compiler and
| thought it was good.
|
| 0. http://flint.cs.yale.edu/cs421/papers/art-of-
| asm/pdf/FORWARD...
| homarp wrote:
| What are the chances that compiler assisted by GPT can
| match human-generated Assembly?
| topspin wrote:
| That's a compelling question. So much so that I imagine
| someone has already investigated this. I might go seek
| out such work, but whatever I find is likely to already
| be out of date...
|
| Interesting times.
| sylware wrote:
| Some assembly fellows did ask chatGPT for a vectorized
| quicksort (avx2/avx512...). Fixing it may be more painful
| than writing from scratch.
|
| But I think it was with chatGPT 3, not 4, and we would
| have to think about a neural net trained to write
| assembly.
| topspin wrote:
| I'm starting from the assumption that the vast bulk of
| hand optimized assembly does not elaborate on the
| thinking behind the implementation in a way that can be
| processed through training. Certainly not assembly
| obtained by reverse engineering. Assuming I'm correct,
| does this mean there is a dearth of training material
| available for building such a model?
|
| It would seem that first one would need a model that
| could consume arbitrary assembly and somehow discover
| it's intent, generate 'labels' (apologies if I'm misusing
| terms here,) and they feed the output into another model.
| sylware wrote:
| It seems that major compilers, gcc and clang are now
| suffering some sort of "planned obsolescence": ISO C is
| always adding stuff, then somebody will manage to use the
| new stuff in some critical system components and will force
| everbody to upgrade. It is even more accute with gcc
| extensions and linux for instance. It seems ISO C planned
| obsolescence does happen on a longer time cycle than gcc
| extensions for linux code for instance (or the glibc, or
| gcc but even worse: c++11 c++14 c++17
| c++489374892347892374238, c++ is orders of magnitude more
| planned obsolesence troubles than C).
|
| Then actually, they could generate amazing code, I would
| not care less: I am so much angry because of this manic and
| systemic planned obsolescence, I now try to code everything
| in assembly (avoiding grotesque assembly code generators
| and absurd usage of the macro preprocessor).
|
| I write x86_64 assembly code, but I am confident porting to
| risc-v should be brutal but not that hard... and I kind of
| know, it will happen.
| bee_rider wrote:
| I've rarely looked at the output of a compiler and thought
| "that's great!" but on the other hand, the fact that I've
| rarely looked at the output of a compiler at all seems to
| indicate that they've got their priorities straight.
| chrsw wrote:
| Cool. I always thought RISC-V could use a Linaro type of
| organization to help make it easier for people to build and
| develop on RISC-V systems. Sounds like this is it.
| johnklos wrote:
| This is pretty rich coming from companies like NVIDIA and Google,
| both having histories of releasing barely portable, if even
| portable at all, code.
|
| While I can compile and run ArcticFox on my AlphaServer with zero
| work, I dare anyone to try to compile Chrome (or Chromium) for
| any non-mainstream architecture, whether it's sparc64, earmv6hf,
| MIPS, RISC-V, whatever. I'll wait ;)
| Pet_Ant wrote:
| I wonder if with RISC-V there is a chance for all the chips on a
| motherboard's "backstage" to all use the same ISA.
|
| https://news.ycombinator.com/item?id=36127543
| speed_spread wrote:
| A "chance"? Maybe, but would there be anything to gain from
| such uniformity? Big CPUs are made by big teams, just like
| software. And you try to maximize re-use of vetted recipes,
| i.e. no need to reinvent power management. I would assume that
| for specialty backstage processors the core that the specialist
| team already knows is the one that gets used. Even if the
| backstage is disclosed, no code will ever be shared between the
| main cores and the support cores.
| Vt71fcAqt7 wrote:
| Nice to see Rivos mentioned here, even having a vice chair
| position. Besides this, the only other place they have appeared
| in public is in a few kernel patches. The fact that they could
| get vice chair shows that they either have a lot of funding or
| have demoed something impressive to the other companies listed
| here like Google or Samsung. Not surprising per se as they have a
| lot of former PA semi/Apple employees but still nice to see
| something showing they aren't vaporware.
| snvzz wrote:
| Rivos also has been regularly showing up with talks in RISC-V
| events.
|
| Whatever they're developing, they are doing in secret. Based on
| them having their strong teams, we can expect a very high
| performance RISC-V implementation.
___________________________________________________________________
(page generated 2023-05-31 23:00 UTC)