www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should we finally ditch the 32-bit build of dmd?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
next sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
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
parent Temtaime <temtaime gmail.com> writes:
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:
 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.
+100500
Jun 16
prev sibling next sibling parent reply max haughton <maxhaton gmail.com> writes:
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
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
parent reply max haughton <maxhaton gmail.com> writes:
On Thursday, 17 June 2021 at 05:48:57 UTC, Walter Bright wrote:
 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.
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)
Jun 16
parent Walter Bright <newshound2 digitalmars.com> writes:
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
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
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
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
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
parent max haughton <maxhaton gmail.com> writes:
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:
 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`.
Wat
Jun 16
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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
prev sibling next sibling parent Claude <claudemr live.fr> writes:
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
prev sibling next sibling parent reply Guillaume Piolat <first.name domain.tld> writes:
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
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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
prev sibling parent reply Claude <claudemr live.fr> writes:
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
parent IGotD- <nise nise.com> writes:
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