D design problem on platforms with <32 bit pointer width (page 2)

On Sunday, 20 August 2023 at 20:06:29 UTC, Richard (Rikki) Andrew Cattermole wrote: > On 21/08/2023 7:13 AM, Walter Bright wrote: >> Keep integer promotion, but have it promote to short rather than int. I haven't thought about it deeply, but first impression says that it will resolve most of the issues. > > This does beg another question. Should we make integer promotion tied to the largest general purpose (fast) registers for a given target? So AMD64 that'll be (u)long. Whereas 16bit x86 that'll be (u)short. Please don't make this discussion any larger than it should be. -Johan

On Sunday, 20 August 2023 at 19:15:13 UTC, Walter Bright wrote: > To be clear, my proposal would mean that size_t would be an alias for ushort, and ptrdiff_t would be an alias for short. Hi Walter, To have a more productive discussion, can you go through the table in my comment on the gist and look at the proposal column? I think it captures what you wrote. Forums posts are not suited for this, we need clear definitions and a full overview. There are too many cases to keep track of, hence the table I made. (and I am sure there are a bunch of items still missing from the table) Please add additional corner cases you can come up with. Just a piece of code with an unresolved 16-bit question is OK, proposed solution is optional (that can be filled in later). thanks, Johan

On 8/19/2023 3:09 AM, Dukc wrote: > This is a request for comments. I've written it as a Git gist as opposed to forum post because it's pretty long and may warrant some editing at some point. > > Link: https://gist.github.com/dukc/04ea4d4a248ff4709f89d5808f67a5fe > > Discussion can remain here though. Ok, it looks like the same as the "16bit Arch Proposal size_t=16bit, integer promotion to short" column. Looks like you beat me to it!

On 21/08/2023 7:13 AM, Walter Bright wrote: > Some things are impractical for D: > > 1. mixed near/far pointers I've been thinking about this and I don't think that this is true. Add two new core.attributes udas. ``enum near;`` and ``enum far;`` If we need segment support ``enum uda(string segment:"FS");`` would suffice. Require it on all variable declarations, easy! Oh and don't forget to do matching of argument/expression validation to declaration for @safe code.

On 8/20/2023 8:48 PM, Richard (Rikki) Andrew Cattermole wrote: > On 21/08/2023 7:13 AM, Walter Bright wrote: >> Some things are impractical for D: >> >> 1. mixed near/far pointers > > I've been thinking about this and I don't think that this is true. I've lived with that problem for 20 years. If there was an answer, one of the compiler vendors would have found it. It's ugly, and there are all kinds of problems with it. Interestingly, C++ compilers designed from the ground up to support multiple pointer types did work, up to a point. Compilers designed for 32 bit processors were never ported to near/far. It would be like a cyclone let loose on its innards. > Add two new core.attributes udas. > > ``enum near;`` and ``enum far;`` > > If we need segment support ``enum uda(string segment:"FS");`` would suffice. > > Require it on all variable declarations, easy! Oh and don't forget to do matching of argument/expression validation to declaration for @safe code. That's only the beginning of the problems.

August 22, 2023

Re: D design problem on platforms with <32 bit pointer width

Posted by Dukc
in reply to Walter Bright

Permalink

Dukc

Posted in reply to Walter Bright

Permalink

On Sunday, 20 August 2023 at 19:13:36 UTC, Walter Bright wrote:

So, I propose the following modification for 16 bit code generation:

Keep integer promotion, but have it promote to short rather than int. I haven't thought about it deeply, but first impression says that it will resolve most of the issues.

"for 16 bit code generation" - meaning, the int promotion target won't change for 32-bit platforms?

This will require changing many of the ints in the source code to shorts. How onerous that would be, I do not know. One could do something like:

I think this is otherwise actually good, but has one annoying trait left: integer literals. To make you code portable, you'll have to wrap your integers when doing pointer arithmetic or handling array lengths: ptr += size_t(3) or new ubyte[oldArr.length + size_t(3)]. But this one does not have the performance problems of the 32-bit size_t solution I initially was in favour of.

Still, I'd prefer changing the value range propagation rules instead as that:

works exactly the same way regardless of pointer width.
does not mandate wrapping in literals with size_t or ptrdiff_t constructor.
makes non memory address related 8 and 16 bit arithmetic more confortable to do while there.

But either solution is a lot better than the current situation, at least when going by what the spec says.

On Monday, 21 August 2023 at 03:48:04 UTC, Richard (Rikki) Andrew Cattermole wrote:

On 21/08/2023 7:13 AM, Walter Bright wrote:

Some things are impractical for D:

mixed near/far pointers

I've been thinking about this and I don't think that this is true.

Add two new core.attributes udas.

enum near; and enum far;

If we need segment support enum uda(string segment:"FS"); would suffice.

Require it on all variable declarations, easy! Oh and don't forget to do matching of argument/expression validation to declaration for @safe code.

I don't think we need to discuss near/far pointers here. This is about your regular monosize pointers that just happen to be under 32 bits. You not have the far pointer option at all. What to do when the platform has two different pointer widths, be they 16/32 or 32/64, is a different question.