digitalmars.D - Should we finally ditch the 32-bit build of dmd?
- Andrei Alexandrescu (5/5) Jun 16 2021 By numerous reports the world is ditching 32 bit for good:
- Vladimir Panteleev (6/11) Jun 16 2021 A good time to do this would be when the minimally supported
- IGotD- (3/8) Jun 16 2021 Ditch dmd completely.
- Temtaime (2/13) Jun 16 2021 +100500
- max haughton (12/17) Jun 16 2021 Perhaps we can start by ditching the schedulers for Pentium chips
- Walter Bright (6/12) Jun 16 2021 At one point, Intel did release a low power 32 bit chip for embedded sys...
- max haughton (10/25) Jun 16 2021 Compile times?
- Walter Bright (11/19) Jun 17 2021 The DMD scheduler is mostly table driven.
- Dukc (15/20) Jun 16 2021 No, I don't think that's a good idea.
- zjh (6/7) Jun 16 2021 As a productivity tool, you rely on 32 bits.
- max haughton (2/10) Jun 16 2021 Wat
- Walter Bright (3/5) Jun 16 2021 Not sure I agree with that. Besides, it's just good practice to not fall...
- Claude (10/15) Jun 17 2021 I would not ditch.
- Guillaume Piolat (7/12) Jun 17 2021 Could this wait a few years instead?
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (4/8) Jun 17 2021 I think this is only about the dmd backend?
- Claude (10/15) Jun 17 2021 I would not ditch.
- IGotD- (11/14) Jun 17 2021 Yes, there might be 32-bit x86 systems and just because of this I
By numerous reports the world is ditching 32 bit for good: https://www.androidauthority.com/arm-32-vs-64-bit-explained-1232065/ There's significant effort needed in the dmd source code to accommodate 32 bit builds, which nobody should use. Ditch?
Jun 16 2021
Vladimir Panteleev <thecybershadow.lists gmail.com> On Wednesday, 16 June 2021 at 17:59:06 UTC, Andrei Alexandrescu wrote:By numerous reports the world is ditching 32 bit for good: https://www.androidauthority.com/arm-32-vs-64-bit-explained-1232065/ There's significant effort needed in the dmd source code to accommodate 32 bit builds, which nobody should use. Ditch?A good time to do this would be when the minimally supported Windows version is bumped to a version which does not have a 32-bit edition. Until then, probably not.
Jun 16 2021
On Wednesday, 16 June 2021 at 17:59:06 UTC, Andrei Alexandrescu wrote:By numerous reports the world is ditching 32 bit for good: https://www.androidauthority.com/arm-32-vs-64-bit-explained-1232065/ There's significant effort needed in the dmd source code to accommodate 32 bit builds, which nobody should use. Ditch?Ditch dmd completely.
Jun 16 2021
On Wednesday, 16 June 2021 at 18:52:52 UTC, IGotD- wrote:On Wednesday, 16 June 2021 at 17:59:06 UTC, Andrei Alexandrescu wrote:+100500By numerous reports the world is ditching 32 bit for good: https://www.androidauthority.com/arm-32-vs-64-bit-explained-1232065/ There's significant effort needed in the dmd source code to accommodate 32 bit builds, which nobody should use. Ditch?Ditch dmd completely.
Jun 16 2021
On Wednesday, 16 June 2021 at 17:59:06 UTC, Andrei Alexandrescu wrote:By numerous reports the world is ditching 32 bit for good: https://www.androidauthority.com/arm-32-vs-64-bit-explained-1232065/ There's significant effort needed in the dmd source code to accommodate 32 bit builds, which nobody should use. Ditch?Perhaps we can start by ditching the schedulers for Pentium chips from the 90s - even charitably (i.e. The P6 architecture did live for a while) it's obsolete (and more importantly not needed for supporting those targets). That way we gain experience pressing delete rather than making the code dead and leaving it, and we reduce the surface area of old/dead code which could be silently broken if other things change around it. Andrei, you may recall this was discussed in a meeting gone by, and Walter seemed to agree in principle to some changes (this one wasn't discussed) to the older parts of the compiler.
Jun 16 2021
On 6/16/2021 2:38 PM, max haughton wrote:Perhaps we can start by ditching the schedulers for Pentium chips from the 90s - even charitably (i.e. The P6 architecture did live for a while) it's obsolete (and more importantly not needed for supporting those targets). That way we gain experience pressing delete rather than making the code dead and leaving it, and we reduce the surface area of old/dead code which could be silently broken if other things change around it.At one point, Intel did release a low power 32 bit chip for embedded systems that benefited quite a bit from the Pentium scheduler, as that chip had sacrificed its own internal scheduler. Besides, the bugs have been sorted out from that scheduler long ago. It's not impairing anyone.
Jun 16 2021
On Thursday, 17 June 2021 at 05:48:57 UTC, Walter Bright wrote:On 6/16/2021 2:38 PM, max haughton wrote:Compile times? OT: I've been reading chunks of the GCC instruction schedulers recently, and I can report that they'd be much more readable (and safer, obviously) in D. The actual approach taken for the OoO monster-cpus we have now (New Apple chips have *16* execution units) isn't totally dissimilar to the code in dmd, just more general (It's effectively an in-order scheduler specifically aimed at the decoder, but the state machine can be generated from the machine description files rather than ad-hoc in code)Perhaps we can start by ditching the schedulers for Pentium chips from the 90s - even charitably (i.e. The P6 architecture did live for a while) it's obsolete (and more importantly not needed for supporting those targets). That way we gain experience pressing delete rather than making the code dead and leaving it, and we reduce the surface area of old/dead code which could be silently broken if other things change around it.At one point, Intel did release a low power 32 bit chip for embedded systems that benefited quite a bit from the Pentium scheduler, as that chip had sacrificed its own internal scheduler. Besides, the bugs have been sorted out from that scheduler long ago. It's not impairing anyone.
Jun 16 2021
On 6/16/2021 11:33 PM, max haughton wrote:Compile times?Perhaps, but it only runs on optimized builds.OT: I've been reading chunks of the GCC instruction schedulers recently, and I can report that they'd be much more readable (and safer, obviously) in D. The actual approach taken for the OoO monster-cpus we have now (New Apple chips have *16* execution units) isn't totally dissimilar to the code in dmd, just more general (It's effectively an in-order scheduler specifically aimed at the decoder, but the state machine can be generated from the machine description files rather than ad-hoc in code)The DMD scheduler is mostly table driven. The tedium with it is creating the tables. It's not fun, mainly because there are *so many* instructions, and the probability of error. Did the gcc compiler guys write the machine description files, too? I suppose that's probably an easier way, as one could make a specialized language for it that is convenient. After all, for a compiler guy, writing a specialized table language is a piece of cake :-) BTW, many of the old handmade tables in the DMD backend were replaced with CTFE-generated tables. A really nice improvement.
Jun 17 2021
On Wednesday, 16 June 2021 at 17:59:06 UTC, Andrei Alexandrescu wrote:By numerous reports the world is ditching 32 bit for good: https://www.androidauthority.com/arm-32-vs-64-bit-explained-1232065/ There's significant effort needed in the dmd source code to accommodate 32 bit builds, which nobody should use. Ditch?No, I don't think that's a good idea. Ditching x86-32 as a host platform should not benefit much. The compiler is written in D after all, it's not like it's hard to keep a program compiling for different architectures. Ditching x86-32 as a target platform would be ditching a platform that's still in wide use for a long time. From the article you linked to: "For other CPU architectures and other OS’s, like Windows and Linux, then 32-bit support will survive much longer. Since Linux wants to be everyone’s friend, then 32-bit support is likely to stay for decades to come". 32-bit might not be very relevant for desktop computers or phones anymore, but there is also IoT, and D is supposed to be a general-purpose language after all.
Jun 16 2021
On Wednesday, 16 June 2021 at 17:59:06 UTC, Andrei Alexandrescu wrote:By numerous reports the world is ditching 32 bit for good:As a productivity tool, you rely on 32 bits. You can't give up 32 bits because there are too many configurations. When you move to 64 bit, your productivity `big drops`.
Jun 16 2021
On Thursday, 17 June 2021 at 00:52:25 UTC, zjh wrote:On Wednesday, 16 June 2021 at 17:59:06 UTC, Andrei Alexandrescu wrote:WatBy numerous reports the world is ditching 32 bit for good:As a productivity tool, you rely on 32 bits. You can't give up 32 bits because there are too many configurations. When you move to 64 bit, your productivity `big drops`.
Jun 16 2021
On 6/16/2021 10:59 AM, Andrei Alexandrescu wrote:There's significant effort needed in the dmd source code to accommodate 32 bit builds,Not sure I agree with that. Besides, it's just good practice to not fall into the trap of assuming size_t is 8.
Jun 16 2021
On Wednesday, 16 June 2021 at 17:59:06 UTC, Andrei Alexandrescu wrote:By numerous reports the world is ditching 32 bit for good: https://www.androidauthority.com/arm-32-vs-64-bit-explained-1232065/ There's significant effort needed in the dmd source code to accommodate 32 bit builds, which nobody should use. Ditch?I would not ditch. 32-bit is still useful on embedded devices. Also, some applications do not necessarily need to address 4GB of memory. I read WebAssembly FAQ, and it says interesting stuff on the subject by the way. See section "Why have wasm32 and wasm64, instead of just an abstract size_t?" and also "Why have wasm32 and wasm64, instead of just using 8 bytes for storing pointers?". https://webassembly.org/docs/faq/#will-webassembly-support-view-source-on-the-web
Jun 17 2021
On Wednesday, 16 June 2021 at 17:59:06 UTC, Andrei Alexandrescu wrote:By numerous reports the world is ditching 32 bit for good: https://www.androidauthority.com/arm-32-vs-64-bit-explained-1232065/ There's significant effort needed in the dmd source code to accommodate 32 bit builds, which nobody should use. Ditch?Could this wait a few years instead? Between 10% and 20% of our userbase are still in need of 32-bit software, for network effect reasons. Of course, if the D core team want to forego one architecture, we'll just use an older compiler for this target.
Jun 17 2021
On Thursday, 17 June 2021 at 10:44:36 UTC, Guillaume Piolat wrote:Between 10% and 20% of our userbase are still in need of 32-bit software, for network effect reasons. Of course, if the D core team want to forego one architecture, we'll just use an older compiler for this target.I think this is only about the dmd backend? Surely ldc/gdc must support 32 bits "forever" in order to support embedded CPUs?
Jun 17 2021
On Wednesday, 16 June 2021 at 17:59:06 UTC, Andrei Alexandrescu wrote:By numerous reports the world is ditching 32 bit for good: https://www.androidauthority.com/arm-32-vs-64-bit-explained-1232065/ There's significant effort needed in the dmd source code to accommodate 32 bit builds, which nobody should use. Ditch?I would not ditch. 32-bit is still useful on embedded devices. Also, some applications do not necessarily need to address 4GB of memory. I read WebAssembly FAQ, and it says interesting stuff on the subject by the way. See section "Why have wasm32 and wasm64, instead of just an abstract size_t?" and also "Why have wasm32 and wasm64, instead of just using 8 bytes for storing pointers?". https://webassembly.org/docs/faq/#will-webassembly-support-view-source-on-the-web
Jun 17 2021
On Thursday, 17 June 2021 at 11:47:08 UTC, Claude wrote:I would not ditch. 32-bit is still useful on embedded devices. Also, some applications do not necessarily need to address 4GB of memory.Yes, there might be 32-bit x86 systems and just because of this I say we should ditch dmd. I knew this were coming, that the dmd backend would be gradually abandoned because of lack of resources. Also, GDC/LDC offers a range of x86 micro architectures to optimize for which is out of scope for dmd. This is particularly interesting for embedded systems that often use odd x86 CPUs. This will eventually happen to x86-64 as well and I'm starting the timer. Instead D should take advantage of CPU support that comes with GDC/LDC and the infrastructure around them.
Jun 17 2021