[HN Gopher] 128-bit RISC-V assembler
___________________________________________________________________
128-bit RISC-V assembler
Author : ingve
Score : 23 points
Date : 2021-09-19 11:43 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| b0tzzzzzzman wrote:
| Looking for insight from people who work at low level optimising
| of code, instruction sets, and hardware.
|
| 1. Do you see 128bit processors/systems becoming mainstream
| anytime in the near future?
|
| 2. What type of applications would benefit consumers and general
| computing at scale?
|
| 3. Do we know of any of the main players working on these?
| mrlonglong wrote:
| Are there any 128-bit core done yet in FPGA?
| baybal2 wrote:
| Who needs 2^128 integers?
| sedatk wrote:
| Evergreen comment, "2^128" being an arbitrary upper limit.
| hdjjhhvvhga wrote:
| It opens up some very interesting possibilities and
| optimization options that you wouldn't normally ever consider.
| In any case, I think programmers of most languages wouldn't
| even need to care as all optimizations would be done by the
| teams working on the compilers/interpreters/VMs.
|
| Note that it's not just about integers, floating point would
| also benefit from this.
| mrlonglong wrote:
| You can use tagged pointers for memory protection.
| ruslan wrote:
| SCALL instruction, used in his example, has been renamed to
| ECALL. Not a big deal though.
| fwsgonzo wrote:
| Good catch. I will rename it to ecall and provide an alias for
| syscall instead.
| nynx wrote:
| When you need a pointer that can address any byte that has or
| will ever exist.
| phkahler wrote:
| And here I was thinking 48 bits would be optimal for a lot of
| things. From address space to posits and instruction lengths
| (actually 24 is probably better there).
| ruslan wrote:
| Although I completely agree with you, I cannot help but
| remember "640K ought to be enough for anyone" by W.H. Gates.
___________________________________________________________________
(page generated 2021-09-19 23:02 UTC)