www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - size_t.sizeof == 2 && __LINE__.sizeof == 4

reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
Hello,

We have a few cases where __LINE__ is assigned to a size_t. For 
instance:

     class Exception : Throwable
     {
          nogc  safe pure nothrow this(string msg, string file = 
__FILE__, size_t line = __LINE__, Throwable next = null)
         {
             super(msg, file, line, next);
         }

__LINE__ is currently defined as 32 bits in LineInitExp 
(Type.tint32). For 32 and 64 bit targets these assignments are 
not a problem (they are either a plain copy or a 0 extension), 
but for 16 bit targets (e.g. MSP430) these are problematic 
because you can't assign the 32-bit __LINE__ value to the 16-bit 
size_t line variable without a cast.

IMO, using size_t for lines is silly, for several reasons:

1. There's no reason why 16-bit targets can't have source code 
with more than 64 K lines;

2. There's probably no good reason to support more than 4 B lines 
of source code;

3. If we *do* want support more than 4 B lines of source code, 
there's no reason to make that support conditional on whether the 
*target* is 32- or 64-bit. Even if we assume the compiler has to 
hold all of the lines in main memory, that's a property of the 
host, not the target.

If see a few ways to move forward:

1) Change `size_t line` to `int line`. The line is already 32 
bits under the covers (and I don't see the need to change that). 
The only issue might be code breakage.

2) Make __LINE__ 16-bit for 16-bit targets. I don't think this 
option makes much sense.

3) Create a line_t type (in object.d?). Make it 32-bit for 16- 
and 32-bit targets, and 64-bit for 64-bit targets. That's for 
avoiding breakage, not because >4 B lines is actually needed, IMO.

I suggest following 3 -- even though I think option 1 would be 
the right one for a day-1 design. (This option also allows 
eventually making line_t 32-bit on 64-bit targets, if people 
start using line_t instead of size_t).

What do you think?

Luís
Jul 10 2017
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/10/17 8:41 AM, Luís Marques wrote:


 1) Change `size_t line` to `int line`. The line is already 32 bits under 
 the covers (and I don't see the need to change that). The only issue 
 might be code breakage.


Not might, will. All exception derivatives call super(msg, file, line), 
which won't work if your exception defines its ctor with size_t line = 
__LINE__.


 2) Make __LINE__ 16-bit for 16-bit targets. I don't think this option 
 makes much sense.


Agree.


 3) Create a line_t type (in object.d?). Make it 32-bit for 16- and 
 32-bit targets, and 64-bit for 64-bit targets. That's for avoiding 
 breakage, not because >4 B lines is actually needed, IMO.


Only sensible option at this point. And I agree it should be done.

-Steve
Jul 10 2017
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, July 10, 2017 9:22:01 AM MDT Steven Schveighoffer via 
Digitalmars-d wrote:

 On 7/10/17 8:41 AM, Luís Marques wrote:

 1) Change `size_t line` to `int line`. The line is already 32 bits under
 the covers (and I don't see the need to change that). The only issue
 might be code breakage.


 Not might, will. All exception derivatives call super(msg, file, line),
 which won't work if your exception defines its ctor with size_t line =
 __LINE__.


 2) Make __LINE__ 16-bit for 16-bit targets. I don't think this option
 makes much sense.




I didn't think that D supported 16-bit targets at all. Do ldc and/or gdc
support 16-bit targets of some kind?

- Jonathan M Davis
Jul 10 2017
parent reply =?UTF-8?Q?Lu=c3=ads_Marques?= <luis luismarques.eu> writes:
On 10/07/2017 14:31, Jonathan M Davis via Digitalmars-d wrote:

 I didn't think that D supported 16-bit targets at all. Do ldc and/or gdc
 support 16-bit targets of some kind?


LDC accepts -mtriple=msp430 with some small tweaks. This issue arose as 
I as working on a proper implementation of those tweaks, to be accepted 
for inclusion in LDC.
Jul 10 2017
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 10 July 2017 at 17:56, Luís Marques via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 10/07/2017 14:31, Jonathan M Davis via Digitalmars-d wrote:

 I didn't think that D supported 16-bit targets at all. Do ldc and/or gdc
 support 16-bit targets of some kind?



 LDC accepts -mtriple=msp430 with some small tweaks. This issue arose as I as
 working on a proper implementation of those tweaks, to be accepted for
 inclusion in LDC.


The official stance is that we don't.  There is just far too much
baggage that gets piled in by default that makes it very hostile,
however those of us who are capable of doing so won't try to stop you,
and you have the likes of minilibd and other minimal D libraries as
friendly replacement, perhaps you could even use them on top of musl.
;-)

The same arguments that are normally brought up about C++ being used
on 16bit processors also apply to D I guess.

Iain.
Jul 10 2017
parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Monday, 10 July 2017 at 17:32:01 UTC, Iain Buclaw wrote:

 The official stance is that we don't.  There is just far too 
 much baggage that gets piled in by default that makes it very 
 hostile, however those of us who are capable of doing so won't 
 try to stop you, and you have the likes of minilibd and other 
 minimal D libraries as friendly replacement, perhaps you could 
 even use them on top of musl. ;-)


By "we don't" it seems you are referring to supporting D + 
druntime + Phobos. But, to clarify, plain -betterC D seems to 
work well. One issue is that size_t currently has the wrong size, 
and changing it involves at least some druntime support (changing 
object.d, and changing all of the size_t line = __LINE__ fallout).

BTW, I wasn't sure how I should go about changing druntime and 
Phobos regarding the size_t line -> line_t line transition. I 
opted to change LDC's fork of druntime first, because it seemed 
to me like the contribution had a better chance of being 
accepted, and afterwards make a separate dlang/druntime pull 
request. But the more natural way would probably be to change the 
canonical druntime first and then merge the changes on the LDC 
side, no?

- Luís
Jul 10 2017
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/10/17 1:49 PM, Luís Marques wrote:

 On Monday, 10 July 2017 at 17:32:01 UTC, Iain Buclaw wrote:

 The official stance is that we don't.  There is just far too much 
 baggage that gets piled in by default that makes it very hostile, 
 however those of us who are capable of doing so won't try to stop you, 
 and you have the likes of minilibd and other minimal D libraries as 
 friendly replacement, perhaps you could even use them on top of musl. ;-)


 
 By "we don't" it seems you are referring to supporting D + druntime + 
 Phobos. But, to clarify, plain -betterC D seems to work well. One issue 
 is that size_t currently has the wrong size, and changing it involves at 
 least some druntime support (changing object.d, and changing all of the 
 size_t line = __LINE__ fallout).


I think it's reasonable to instrument druntime/phobos with line_t, and 
then libraries may or may not work with 16-bit (I wouldn't be surprised 
if most don't), but at least they will likely work for files less than 
65k lines (quite a few) :)

e.g. this should work fine if super takes a line_t:

class MyException : Exception
{
   this(string msg, size_t line = __LINE__, string file = __FILE__)
   {
     super(msg, line, file);
   }
}

I will review and approve such a request if you make it. You'd likely 
need buy-in from Andrei.

-Steve
Jul 10 2017
parent =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Monday, 10 July 2017 at 18:03:27 UTC, Steven Schveighoffer 
wrote:

 I think it's reasonable to instrument druntime/phobos with 
 line_t, and then libraries may or may not work with 16-bit (I 
 wouldn't be surprised if most don't), but at least they will 
 likely work for files less than 65k lines (quite a few) :)


Right, since for 32- and 64-bit code line_t is an alias for 
size_t, nothing breaks.


 I will review and approve such a request if you make it. You'd 
 likely need buy-in from Andrei.


That's nice. So maybe I should submit for the canonical druntime 
first and ask for a merge on the LDC side?

BTW, if you want to help bikeshed the name for the 16-bit version 
identifier name, there's still time... 
<https://github.com/ldc-developers/ldc/pull/2194#issuecomment-314174622>

D_P16? D_16? Something else?
Jul 10 2017
prev sibling parent Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 7/10/17 10:49 AM, Luís Marques via Digitalmars-d wrote:

 On Monday, 10 July 2017 at 17:32:01 UTC, Iain Buclaw wrote:

 The official stance is that we don't.  There is just far too much 
 baggage that gets piled in by default that makes it very hostile, 
 however those of us who are capable of doing so won't try to stop you, 
 and you have the likes of minilibd and other minimal D libraries as 
 friendly replacement, perhaps you could even use them on top of musl. ;-)


 
 By "we don't" it seems you are referring to supporting D + druntime + 
 Phobos. But, to clarify, plain -betterC D seems to work well. One issue 
 is that size_t currently has the wrong size, and changing it involves at 
 least some druntime support (changing object.d, and changing all of the 
 size_t line = __LINE__ fallout).
 
 BTW, I wasn't sure how I should go about changing druntime and Phobos 
 regarding the size_t line -> line_t line transition. I opted to change 
 LDC's fork of druntime first, because it seemed to me like the 
 contribution had a better chance of being accepted, and afterwards make 
 a separate dlang/druntime pull request. But the more natural way would 
 probably be to change the canonical druntime first and then merge the 
 changes on the LDC side, no?
 
 - Luís


I think this is a great example of a project where the best path is to 
fork the compiler, runtime, and phobos (if you intend to go that high up 
the stack) and just go do it.  Don't worry, for the short term, about 
any of the naming issues, mergability, etc.  Make it work, use it, learn 
what the big issues are, etc.  Then, cycle back and look at how to 
merge.  I suspect there's going to be a lot of issues and finding out 
what's important to disucss in what order is useful.  Getting bogged 
down early is going to be frustrating.
Jul 10 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2017 5:41 AM, Luís Marques wrote:

 for 16 bit targets


Having developed C/C++ on 16 bit targets for a couple decades, I have some 
curmudgeonly perspective.

1. having __LINE__ as size_t is madness. If I was responsible for that, shame
on me.

2. a 16 bit type for 16 bit targets is plenty good enough. Consider that 32
bits 
on 16 bit targets is code bloat EXPENSIVE, and code bloat is a huge problem on 
16 bit targets. You're just not going to have 64000 line files, because the 
generated code won't fit in 16 bits. Even if you constructed a case, having the 
counter wrap around is little more than a very minor aggravation.

3. C++ worked on 16 bit code before exceptions and RTTI. Exceptions and RTTI
are 
completely unworkable on 64K machines, and even on 640K machines. The STL is 
completely unworkable on 640K machines, because it is just too big.

4. 640K programming in C++ is not practical without near/far support. D has no 
such support, and neither does Standard C++.

5. C++ on a 64K machine is like using a tank to get to the grocery store.

6. __LINE__ is typed `unsigned` everywhere I've seen, including with 16 bit 
compilers.

== Some Conclusions ==

1. __LINE__ should be `uint`. Negative lines make no sense.

2. Exceptions are useless on 16 bits, so class Exception has no purpose.

3. D doesn't have near/far and won't be suitable for 640K programming.

4. D for 64K programming is possible in 'betterC' mode.

5. D's 32 bit int sizes are not very workable for 16 bit code. shorts will be 
promoted to 32 bits. Trying to change this in the compiler logic for 16 bit 
targets is an unknown amount of work.

6. D for 16 bits wouldn't really be D, it would be a D variant with different 
semantics and capabilities. (Like C++ for 16 bits.)

== Bottom Line ==

Trying to make D into a useful compiler for 16 bit programming is a bit of a 
quixotic quest. But it probably could be bludgeoned into doing something 
credible with it if needed to satisfy a bullet point requirement. __LINE__'s 
type is hardly the only problem.

What is the goal/reason/rationale for making a 16 bit D target?
Jul 10 2017
parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Monday, 10 July 2017 at 19:41:48 UTC, Walter Bright wrote:

 What is the goal/reason/rationale for making a 16 bit D target?


- I program for MSP430
- I'm tired of C's limitation
- LDC works with MSP430
Jul 10 2017
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2017 12:53 PM, Luís Marques wrote:

 On Monday, 10 July 2017 at 19:41:48 UTC, Walter Bright wrote:

 What is the goal/reason/rationale for making a 16 bit D target?


 
 - I program for MSP430
 - I'm tired of C's limitation
 - LDC works with MSP430


Those are quite understandable goals. I'm curious how the issues I brought up 
are addressed, however.
Jul 10 2017