4 ms·
The big difference in that situation is that you need to know whether a pointer is to your code memory or your data memory, most languages assume a single addre
by DSMan195276 4y ago
The big difference in that situation is that you need to know whether a pointer is to your code memory or your data memory, most languages assume a single address space and don't make a distinction. Technically it's possible for the compiler/runtime to track that information and hide it from you but it would have overhead.
If you look at writing C programs for AVR (Harvard architecture) there's a lot of extra stuff provided to allow reading from "program memory", with all regular pointers reading from RAM/data memory.
- bheadmaster 4y agoI see - since most of the currently popular languages are object-oriented and implement inheritance through virtual table of function pointers, that would certainly at least slow things down significantly. Thanks for the clarification.
- josephg 4y ago“Most” of the currently popular languages? That’s true for C++ and maybe Java and C#. Is that true for python or javascript? Swift? It’s definitely not true for newer languages like Scala, rust or zig.
- xmcqdpt2 4y agoScala is object oriented and anyway even if you write non OOP code it ends up (usually) on the JVM so you still get all the virtual tables stuff. If anything idiomatic Scala usually has significantly more pointer indirection than Java.
- bheadmaster 4y agoCPython uses function pointers heavily, although not for vtables, but hash tables (since almost everything in Python is a hash table). I don't know about V8 and JVM, but even if they managed to avoid function pointers, they still rely on JIT compilation, which is as problematic for non-von Neumann architectures, if not worse. I should've phrased things differently not to imply that all of them use vtables - vtables was just the first example that popped to my mind.
- DSMan195276 4y agoWell function pointers are actually an interesting case, function pointers should always refer to the program memory and thus aren't ambiguous. Things like string literals are a problem though, you want them to be in the read-only program memory but most functions just take a `const char ` and have no way of indicating where the string is stored. And on the other side, if you _do_ opt to provide this information on every `const char ` that creates a whole lot of overhead to actually reading the contents of the string.