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
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
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
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
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
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
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
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
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
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