Hi,

I have a project aiming to old 68K processor. While I don't think DMD would be able for this on the other hand I think GDC can, am I right?

If yes would be any restriction of features to be used? Or the compiler would be smart enough to handle this properly?

Edgar V.

On 20/01/2019 1:38 AM, Edgar Vivar wrote:
> Hi,
> 
> I have a project aiming to old 68K processor. While I don't think DMD would be able for this on the other hand I think GDC can, am I right?
> 
> If yes would be any restriction of features to be used? Or the compiler would be smart enough to handle this properly?
> 
> Edgar V.

Potentially.

D is designed to only work on 32bit+ architectures. The 68k series did have 32bit versions of them.

After a quick check it does look like LDC is out as LLVM has not yet got support for M68k target. Which is unfortunate because with the -betterC flag it could have pretty much out of the box worked. Even if you don't have most of D at your disposal e.g. classes and GC (but hey old cpu! can't expect that).

I have no idea about GDC, but the -betterC flag is pretty recent so its support may not be what you would consider first class there yet.

On Saturday, 19 January 2019 at 12:54:28 UTC, rikki cattermole wrote:
> On 20/01/2019 1:38 AM, Edgar Vivar wrote:
>> Hi,
>> 
>> I have a project aiming to old 68K processor. While I don't think DMD would be able for this on the other hand I think GDC can, am I right?
>> 
>> If yes would be any restriction of features to be used? Or the compiler would be smart enough to handle this properly?
>> 
>> Edgar V.
>
> Potentially.
>
> D is designed to only work on 32bit+ architectures. The 68k series did have 32bit versions of them.
>
> After a quick check it does look like LDC is out as LLVM has not yet got support for M68k target. Which is unfortunate because with the -betterC flag it could have pretty much out of the box worked. Even if you don't have most of D at your disposal e.g. classes and GC (but hey old cpu! can't expect that).
>
> I have no idea about GDC, but the -betterC flag is pretty recent so its support may not be what you would consider first class there yet.

At least 68030 (or 68020+68851) would be necessary for proper segfault managing (MMU) and an OS that uses it. Afaict NULL pointer derefernecing must fault for D to be "usable". At least all code is written with that assumption.

On Saturday, 19 January 2019 at 12:54:28 UTC, rikki cattermole wrote:
> I have no idea about GDC, but the -betterC flag is pretty recent so its support may not be what you would consider first class there yet.

so specifically -betterC has been around for years, but it has only recently become somewhat usable in dmd.

The pre-built gdc won't work well with -betterC but a custom built one... might. Probably not though.

On Saturday, January 19, 2019 10:45:41 AM MST Patrick Schluter via Digitalmars-d-learn wrote:
> On Saturday, 19 January 2019 at 12:54:28 UTC, rikki cattermole
>
> wrote:
> > On 20/01/2019 1:38 AM, Edgar Vivar wrote:
> >> Hi,
> >>
> >> I have a project aiming to old 68K processor. While I don't think DMD would be able for this on the other hand I think GDC can, am I right?
> >>
> >> If yes would be any restriction of features to be used? Or the compiler would be smart enough to handle this properly?
> >>
> >> Edgar V.
> >
> > Potentially.
> >
> > D is designed to only work on 32bit+ architectures. The 68k series did have 32bit versions of them.
> >
> > After a quick check it does look like LDC is out as LLVM has not yet got support for M68k target. Which is unfortunate because with the -betterC flag it could have pretty much out of the box worked. Even if you don't have most of D at your disposal e.g. classes and GC (but hey old cpu! can't expect that).
> >
> > I have no idea about GDC, but the -betterC flag is pretty recent so its support may not be what you would consider first class there yet.
>
> At least 68030 (or 68020+68851) would be necessary for proper segfault managing (MMU) and an OS that uses it. Afaict NULL pointer derefernecing must fault for D to be "usable". At least all code is written with that assumption.

For @safe to work properly, dereferencing null must be @safe, which means more or less means that either it results in a segfault, or the compiler has to add additional checks to ensure that null isn't dereferenced. The situation does get a bit more complicated in the details (e.g. calling a non-virtual member function on a null pointer or reference wouldn't segfault if the object's members are never actually accessed, and that's fine, because it doesn't violate @safe), but in general, either a segfault must occur, or the compiler has to add extra checks so that invalid memory is not accessed. At this point, AFAIK, all of the D compilers assume that dereferencing null will segfault, and they don't ever add additional checks. If an architecture does not segfault when dereferencing null, then it will need special handling by the compiler, and I don't think that ever happens right now. So, if D were compiled on such an architecture, @safe wouldn't provide the full guarantees that it's supposed to.

- Jonathan M Davis

On Sunday, 20 January 2019 at 09:27:33 UTC, Jonathan M Davis wrote:
> On Saturday, January 19, 2019 10:45:41 AM MST Patrick Schluter via Digitalmars-d-learn wrote:
>> On Saturday, 19 January 2019 at 12:54:28 UTC, rikki cattermole
>>
>> wrote:
>> > [...]
>>
>> At least 68030 (or 68020+68851) would be necessary for proper segfault managing (MMU) and an OS that uses it. Afaict NULL pointer derefernecing must fault for D to be "usable". At least all code is written with that assumption.
>
> For @safe to work properly, dereferencing null must be @safe, which means more or less means that either it results in a segfault, or the compiler has to add additional checks to ensure that null isn't dereferenced. The situation does get a bit more complicated in the details (e.g. calling a non-virtual member function on a null pointer or reference wouldn't segfault if the object's members are never actually accessed, and that's fine, because it doesn't violate @safe), but in general, either a segfault must occur, or the compiler has to add extra checks so that invalid memory is not accessed. At this point, AFAIK, all of the D compilers assume that dereferencing null will segfault, and they don't ever add additional checks. If an architecture does not segfault when dereferencing null, then it will need special handling by the compiler, and I don't think that ever happens right now. So, if D were compiled on such an architecture, @safe wouldn't provide the full guarantees that it's supposed to.
>

Ok, thanks for the explanation. This said, my statement that a PMMU is required for NULL pointer segfaults is wrong. Even 68000 can segfault on NULL dereference in user mode at least (the famous bus error 2 bombs on Atari ST or guru meditations on Amiga). In priviledged mode though it's not the case as there is memory at address 0 (reset vector) that might be necessary to access by an OS.

On Saturday, 19 January 2019 at 17:45:41 UTC, Patrick Schluter wrote:
> Afaict NULL pointer derefernecing must fault for D to be "usable". At least all code is written with that assumption.

Dereferencing `null` in D is implementation defined (https://dlang.org/spec/arrays.html#pointers).

For LDC, dereferencing `null` invokes Undefined Behavior [1]. However, the compiler does try to be a little friendly towards the programmer. UB includes just ignoring the dereference, but if you are blatantly dereferencing `null` with optimization enabled, the compiler generates a `ud2` instruction for you:
https://d.godbolt.org/z/5VLjFt

-Johan

[1] Now I am not quite sure yet whether Undefined Behavior is part of the set of behaviors allowed to choose from for Implementation Defined behavior. ;-)

On Monday, 21 January 2019 at 17:08:23 UTC, Johan Engelen wrote:
>
> For LDC, dereferencing `null` invokes Undefined Behavior [1].

For completeness, you can tell LDC that dereferencing `null` is _not_ UB in a particular function by specifying `@llvmAttr("null-pointer-is-valid", "true")`:

https://d.godbolt.org/z/1FQCRf

-Johan

Hi...none of the 68k family are 100% compatible - The 68060 has many opcodes
that did not exist in the 68000, and the 68000 has addressing modes that
are missing from the 68060. The same applies to the ColdFire. Still,
the ISA is the same.

On Monday, January 21, 2019 10:08:23 AM MST Johan Engelen via Digitalmars-d- learn wrote:
> On Saturday, 19 January 2019 at 17:45:41 UTC, Patrick Schluter
>
> wrote:
> > Afaict NULL pointer derefernecing must fault for D to be "usable". At least all code is written with that assumption.
>
> Dereferencing `null` in D is implementation defined
> (https://dlang.org/spec/arrays.html#pointers).
>
> For LDC, dereferencing `null` invokes Undefined Behavior [1]. However, the compiler does try to be a little friendly towards the programmer. UB includes just ignoring the dereference, but if you are blatantly dereferencing `null` with optimization enabled, the compiler generates a `ud2` instruction for you: https://d.godbolt.org/z/5VLjFt
>
> -Johan
>
> [1] Now I am not quite sure yet whether Undefined Behavior is part of the set of behaviors allowed to choose from for Implementation Defined behavior. ;-)

It is my understanding that Walter specifically chose the term "implementation defined" rather than "undefined," because undefined behior is not allowed, and that page you linked to supports that in that it lists "implementation defined" and "undefined" separately when talking about the behavior of dereferencing pointers. But you would have to discuss it with Walter to know exactly what he meant. The spec really should define those terms somewhere, but I doubt that it does. I haven't read through the spec in much detail recently though, so maybe it's in there somewhere.

- Jonathan M Davis