5 ms·

> The vast complexity of modern software and hardware comes from the ever more complex environment they interact with. 100% agree, hence my suggestion to compl

> The vast complexity of modern software and hardware comes from the ever more complex environment they interact with. 100% agree, hence my suggestion to completely remove environment access from the instruction set. No syscall. > It runs on ARM - an easily interpretable instruction set. I give you 2 hours to write a brand new fully spec compliant ARMv8 interpreter, 3 hours to write an android VM to run on my windows laptop. > Discord not running on older phones is entirely due to them depending on newer operating system APIs. It's not the instructions that changed, the environment did. The instructions allowed them to depend on platform specific features, which is what I want to prevent. Instead of calling some random android `external_is_switch_gesture` syscall the app should request a boolean/bit given a string "Has there been a switch gesture?" and expect the result of that syscall to be what they asked for. Then, it would be up to the OS to decide how to interpret that request, maybe that the string is part of some standardized way to retrieve a gesture input in which way automate it, but if it is not you could simply prompt the user to chose what to give the application given a list of all the possible environment access.

ben-schaaf 3y ago
> I give you 2 hours to write a brand new fully spec compliant ARMv8 interpreter, 3 hours to write an android VM to run on my windows laptop. 2 hours is pushing it for pretty much anything. I am pretty confident I can make a 64bit risc-v interpreter that'll boot Linux in a few days. Wouldn't be fast and wouldn't have IO, but neither of those have any baring on how easy the instructions are to interpret. The spec is fairly easy to understand. > The instructions allowed them to depend on platform specific features, which is what I want to prevent. > Instead of calling some random android `external_is_switch_gesture` syscall the app should request a boolean/bit given a string "Has there been a switch gesture?" and expect the result of that syscall to be what they asked for. Ok so in order to make it fast we're not going to use strings, instead integers that we only ever increment for new syscalls (no conflicts, ever). Applications want to know whether the system has support for a syscall, so we return an error if they don't exist. This is how Linux syscalls work. Lets use your hypothetical: I'm writing a game that makes heavy use of switch geatures. I make my game call the "Has there been a switch gesture?" syscall, but whoops switch gestures were added in version 6 but this customer is using version 5. The absense of this syscall is fundamentally incompatible with my game, so I guess I'll put "requires version 6" on the website. This is the status quo. Nothing you've suggested is a fundamental change to how software/hardware works. As long as new things are being invented/written you can never have full backwards compatibility. > but if it is not you could simply prompt the user to chose what to give the application given a list of all the possible environment access. Just to be thorough this is fully possible right now - intercepting unknown syscalls and showing a prompt - but there's simply way too many and their behavior too complex for it to be of any use. Especially non-experts would have exactly zero chance.
- TheMode 3y ago
  > 2 hours is pushing it for pretty much anything. bf could, lambda calculus as well, or potentially cellular automata. Also implementing IO is still important, as the apps depend on it. What I am saying in my case is that the hardware manufacturer should expose the basic hardware features as functions (so immutable, there is nothing to update here) and you would then be able to implement whatever your app is written in and reuse the primitive hardware functions. > Ok so in order to make it fast we're not going to use strings, Why would strings be slower? These would be part of the static binary. These calls being hint and not necessarily standardized is an important part. Standards are the same as environments, they always evolve. > Applications want to know whether the system has support for a syscall, so we return an error if they don't exist. This is how Linux syscalls work. You may want to do something with the call even if the guaranteed syscall isn't there. I am meaning the string as a hint, not as an api > but whoops switch gestures were added in version 6 but this customer is using version 5. The absense of this syscall is fundamentally incompatible with my game, so I guess I'll put "requires version 6" on the website. Switch gestures cannot be linked to a software version. It is hardware. As long as you can listen to touch input and optionally multi-touch you have physical support for all gestures. It being limited to version 6 or above is an arbitrary limitation, and indeed will cause the software to delimit what's supported. Whereas if your software only exposed a "has there been a switch gesture" visible to the users, they could decide that actually a button press should be considered as a switch, or they could use a separate library that convert touch inputs into a yes/no switch, or perhaps that their devices already come with some hardware accelerated switch gesture control that they can plug into it. > As long as new things are being invented/written you can never have full backwards compatibility. The problem is that when making software you are forced to reinvent the whole chain. I simply cannot make a calculator app with the guarantee that it will be able to run decades from now, I need to include the binary that open the window, get the OpenGL context, write the boilerplate so I can draw individual pixels, etc. But what if my compiled program only contained basic flow logic and an input and output? Essentially a function. And when users run it, how that function behaves with the environment is device specific and as the calculator developer I couldn't care any less. Obviously, if you make a VR game it will be pretty hard to emulate it on a gameboy, but there is nothing justifying that I cannot make my own discord port on an arduino (except speed, but this is a convenience) > Just to be thorough this is fully possible right now - intercepting unknown syscalls and showing a prompt - but there's simply way too many and their behavior too complex for it to be of any use. Especially non-experts would have exactly zero chance. I agree, that's because we do not assign proper meaning to these syscalls. Users wouldnt know what to do, I am not saying that we need to expose raw file descriptors or make the user handle async i/o. I however believe that we should make this option more viable, for example by allowing applications to transform whatever they want into an environment request so they become more straightforward. And the less syscall you do, the easier it will be for users to make their ports.

ben-schaaf 3y ago

> I give you 2 hours to write a brand new fully spec compliant ARMv8 interpreter, 3 hours to write an android VM to run on my windows laptop. 2 hours is pushing it for pretty much anything. I am pretty confident I can make a 64bit risc-v interpreter that'll boot Linux in a few days. Wouldn't be fast and wouldn't have IO, but neither of those have any baring on how easy the instructions are to interpret. The spec is fairly easy to understand. > The instructions allowed them to depend on platform specific features, which is what I want to prevent. > Instead of calling some random android `external_is_switch_gesture` syscall the app should request a boolean/bit given a string "Has there been a switch gesture?" and expect the result of that syscall to be what they asked for. Ok so in order to make it fast we're not going to use strings, instead integers that we only ever increment for new syscalls (no conflicts, ever). Applications want to know whether the system has support for a syscall, so we return an error if they don't exist. This is how Linux syscalls work. Lets use your hypothetical: I'm writing a game that makes heavy use of switch geatures. I make my game call the "Has there been a switch gesture?" syscall, but whoops switch gestures were added in version 6 but this customer is using version 5. The absense of this syscall is fundamentally incompatible with my game, so I guess I'll put "requires version 6" on the website. This is the status quo. Nothing you've suggested is a fundamental change to how software/hardware works. As long as new things are being invented/written you can never have full backwards compatibility. > but if it is not you could simply prompt the user to chose what to give the application given a list of all the possible environment access. Just to be thorough this is fully possible right now - intercepting unknown syscalls and showing a prompt - but there's simply way too many and their behavior too complex for it to be of any use. Especially non-experts would have exactly zero chance.

TheMode 3y ago
> 2 hours is pushing it for pretty much anything. bf could, lambda calculus as well, or potentially cellular automata. Also implementing IO is still important, as the apps depend on it. What I am saying in my case is that the hardware manufacturer should expose the basic hardware features as functions (so immutable, there is nothing to update here) and you would then be able to implement whatever your app is written in and reuse the primitive hardware functions. > Ok so in order to make it fast we're not going to use strings, Why would strings be slower? These would be part of the static binary. These calls being hint and not necessarily standardized is an important part. Standards are the same as environments, they always evolve. > Applications want to know whether the system has support for a syscall, so we return an error if they don't exist. This is how Linux syscalls work. You may want to do something with the call even if the guaranteed syscall isn't there. I am meaning the string as a hint, not as an api > but whoops switch gestures were added in version 6 but this customer is using version 5. The absense of this syscall is fundamentally incompatible with my game, so I guess I'll put "requires version 6" on the website. Switch gestures cannot be linked to a software version. It is hardware. As long as you can listen to touch input and optionally multi-touch you have physical support for all gestures. It being limited to version 6 or above is an arbitrary limitation, and indeed will cause the software to delimit what's supported. Whereas if your software only exposed a "has there been a switch gesture" visible to the users, they could decide that actually a button press should be considered as a switch, or they could use a separate library that convert touch inputs into a yes/no switch, or perhaps that their devices already come with some hardware accelerated switch gesture control that they can plug into it. > As long as new things are being invented/written you can never have full backwards compatibility. The problem is that when making software you are forced to reinvent the whole chain. I simply cannot make a calculator app with the guarantee that it will be able to run decades from now, I need to include the binary that open the window, get the OpenGL context, write the boilerplate so I can draw individual pixels, etc. But what if my compiled program only contained basic flow logic and an input and output? Essentially a function. And when users run it, how that function behaves with the environment is device specific and as the calculator developer I couldn't care any less. Obviously, if you make a VR game it will be pretty hard to emulate it on a gameboy, but there is nothing justifying that I cannot make my own discord port on an arduino (except speed, but this is a convenience) > Just to be thorough this is fully possible right now - intercepting unknown syscalls and showing a prompt - but there's simply way too many and their behavior too complex for it to be of any use. Especially non-experts would have exactly zero chance. I agree, that's because we do not assign proper meaning to these syscalls. Users wouldnt know what to do, I am not saying that we need to expose raw file descriptors or make the user handle async i/o. I however believe that we should make this option more viable, for example by allowing applications to transform whatever they want into an environment request so they become more straightforward. And the less syscall you do, the easier it will be for users to make their ports.