6 ms·
Ratification of the RISC-V Base ISA and Privileged Architecture Specifications
- ncmncm 7y agoI just hope it's not too late to make the ABI represent Boolean false with ~0. We won't get another chance to do this right for a long, long time.
- dmitrygr 7y agowhy would you possibly want that? and in what size? byte? long?
- IshKebab 7y agoI think it's helpful for SIMD operations, in some way that I can't quite remember.
- haneefmubarak 7y agoThe reasoning there would be that you could use bitwise operations to mask inputs from two vectors into one (think vectorized conditional move), which effectively allows you to easily achieve performant branch predication. However, you can trivially achieve this the normal way by including simple instructions that allow you to select or combine vector inputs. If that's not a path they want to go down, it's also doable to take a slight performance hit and achieve the same with the use of multiplication instructions.
- nsajko 7y agoPresumably you mean that false should be represented with 0 and true with ~0? And the motivation is maybe to be able to toggle boolean values with one instruction? Has there been any discussion on this matter on risc-v mailing lists or somewhere? If the RISC-V Base ISA is now ratified, I think it is too late to change such things. Edit: seems to be too late. According to [0], SLTx instructions "set the destination register to one or zero depending on whether the relation is true or not." [0] https://www.imperialviolet.org/2016/12/31/riscv.html https://www.imperialviolet.org/2016/12/31/riscv.html
- cesarb 7y ago> And the motivation is maybe to be able to toggle boolean values with one instruction? You can already do that: use XORI with immediate 1 to toggle.
- nsajko 7y agoFun fact: riscv does not even have a machine not instruction. In assembly it is just an alias for xori.
- Vogtinator 7y agoFun fact, neither does AArch64, it uses ORRN with xzr instead.
- ncmncm 7y agoYes, I was hasty. Boolean true should be ~0.
- brianpaul 7y agoConverting true=1 to true=~0 is trivial: negate the value, or subtract from zero.
- JoshTriplett 7y agoThis would utterly break the expectations of anyone coming from another platform, and a substantial amount of existing C code. (Whether that C code was allowed to make that assumption or not, it did.) Leaving aside whether the behavior you propose qualifies as "right": no, I don't think there is any chance to change the encoding of "bool", any more than you can redefine the size of "char" or the value of CHAR_BITS. The world uses 8-bit bytes, the world uses twos-complement (C recently wrote that into the standard), and the world uses 0 for false and 1 for true.
- nwallin 7y agoThere is a concrete advantage to using a scheme where 0 is true and all other values are false: error codes. True means the operation succeeded correctly, or false because of insufficient permissions, false because there file doesn't exist, false because of io error, false because of timeout etc. bash uses this scheme. However, this ship has sailed for general purpose programming languages. 0 is false, all other values are interpreted as true, operations that create a bool create 1. As you say, that's just how the world works. False = ~0 is just zany though.
- JoshTriplett 7y ago> There is a concrete advantage to using a scheme where 0 is true and all other values are false: error codes. True means the operation succeeded correctly, or false because of insufficient permissions, false because there file doesn't exist, false because of io error, false because of timeout etc. bash uses this scheme. That works perfectly fine if you write the type as an integer type and define 0 as "no error". You can't call that a C "bool" though.
- deleted 7y ago[deleted]
- nwallin 7y ago> You can't call that a C "bool" though. Correct. It was not my intent to imply otherwise. Like the person I replied to and I reiterated, that ship has sailed.
- pcwalton 7y agoUnfortunately, we lost the chance decades ago when C became popular.
- beefhash 7y agoNot necessarily. The UNIX C syscall APIs all return 0 on success and anything not-zero is generally considered failure (usually -1). Even if it's wrong in C, it could possibly be more efficient in assembly to change the truthiness assumption around.
- pcwalton 7y agoHack Clang to emit ~0 for true, recompile your kernel and userspace, and see how much of it breaks. I'm almost certain the system won't boot.
- fluffything 7y ago> Hack Clang to emit ~0 for true, recompile your kernel and userspace, and see how much of it breaks. The ABI of your platform might require special values for true and false, e.g., the SysV64 ABI explicitly requires 0 for false, and 1 for true. So you would need to define a new platform for doing these tests, and then to test some code, you would need to port it to this new platform. AFAICT, if you port that code correctly, everything would work, and if something doesn't work, then you didn't port that code correctly. So this experiment feels moot. > I'm almost certain the system won't boot. Clang can't compile the Linux kernel, so I hope you mean some other kernel. Otherwise, without a kernel, the system won't even boot :P
- dmitrygr 7y agoLook at doom's source code for an idea of how often a bool is not just 0 or 1. I doubt doom is unique. Spoiler: doom uses 2 values for bools: 0 for false, 1 for true, and -1 for not sure/unknown/error/something else
- abecedarius 7y agoForth uses ~0. I know this has no weight to speak of, I'm just saying there are a few pockets of sanity in the world.
- fluffything 7y ago+10000000 you deserve to be on the front.
- pm215 7y agoFrom a purely pragmatic point of view, this is probably a bad idea. My take is that new architectures/ABIs get a certain "budget" for doing "weird" things. Every choice you take that isn't the same as existing mainstream architectures (and notably everything that's not the same as x86) is extra work to get the software ecosystem to support your new architecture. So you really want to pick and choose what you're spending your weirdness budget on, because if you blow your budget then the result is that too much software will fail to support your new architecture in a timely way. Another example of this is that there's an argument that an ascending stack would be better than a descending stack -- but almost everybody (HPPA being the only exception I can think of offhand) has a descending stack, so you have to really really believe in the merits of ascending stacks to pick that over "just do what the rest of the world does".
- snvzz 7y agoWhile I haven't looked hard into it, I hope they didn't throw in assumptions that affect context switch speed, particularly on pure microkernel multiserver systems that depend on it and are used in critical applications that require high assurance and low, bounded IPC and interrupt response times.
- DSingularity 7y agoWhat are examples of such systems?
- monocasa 7y agoThe l4 variants don't even clear all the registers on an fast path IPC.
- harry8 7y agoThere are none of any practical use, but we live in hope.
- p_l 7y agoIf you use a phone with a Qualcomm modem you use one such system, based on OKL4 (or at least they used to use OKL4 + L4 Linux for non hard RT parts)
- harry8 7y agoNot a multi-server operating system. Source: worked on it. Unless it changed, L4 is used with additional code co-located as the base-band modem on its own cpu. Small RTOS is not a multi-server micro-kernel based os.
- p_l 7y agoI suspect we might be using different meanings of multi-server microkernel OS, unless the modem software is even more limited than I thought - I meant that the system is composed of multiple communicating servers. Does the modem just have few independent colocated "big" servers (like the ancient 4.2 BSD server for Mach)? EDIT: Also, had some fun in the past learning about the modem software on Qualcomm modems, back before iPhone or Android so nice to meet someone who worked on it :)
- amluto 7y agoI haven’t read the latest version, but early versions had a mechanism for kernel entries that was too simple. An interrupt that happened right after a kernel entry but before any instructions executed would be unrecoverable. A good CPU design should help enough with exceptions and interrupts that state won’t be lost. As an example of the wrong approach, x86’s SYSENTER just switches to kernel mode and updates the program counter. x86’s interrupts are better — they push all clobbered state to the stack.
- monocasa 7y agoI wish they had waited until the riscv-formal work was a little farther on. I have a distinct feeling we're going to uncover some goofiness in the spec from that work.
- fluffything 7y agoAt some point you have to ship, and thanks to the awesomeness of semantic versioning, they can always release RISC-VI :) /s
- panpanna 7y agoThere is no reason "move fast and break things" should not work for hardware too /S