www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Compiling to 68K processor (Maybe GDC?)

reply Edgar Vivar <edgarviv mail.com> writes:
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.
Jan 19 2019
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
Jan 19 2019
next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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.
Jan 19 2019
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Jan 20 2019
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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.
Jan 20 2019
prev sibling parent reply Johan Engelen <j j.nl> writes:
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. ;-)
Jan 21 2019
next sibling parent Johan Engelen <j j.nl> writes:
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
Jan 21 2019
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Jan 21 2019
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
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.
Jan 19 2019
prev sibling parent AvritSase <RochMesa protonmail.com> writes:
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.
Jan 21 2019