www.digitalmars.com         C & C++   DMDScript  

D - Data Types and CPUs and D compiler and more...

reply MicroWizard ax.hu writes:
Referring to many postings from Walter, Pavel, Richard and others...
(I've tried to read all of the news. But it is possible that I've overlooked
some ;-)

Dear All,

The real question is: Must solve every problems with the D _compiler_?
Ex. dependency of stack mechamism, HW word size, other HW structures,
homogenous solution for every projects ...

I think no. It is crazy.

I have worked with many different CPU's for years (Z80, 6502, x86, 68000, PICs,
AVRs and other microcontrollers) there are no standard language nor software
technique to handle all of them. It is the life.

Who works with embedded (or any other illformed) systems (like me :-) should
take care of data sizes, what is well defined in D yet. In other hand he/she
should take care of the amount of data, the software algorythms/techniques also
.. what could be really implemented on the target hardware. (DOOM on a ZX81
 :-)

A language should be able to describe every _problems_&_solutions_ not
implementations.

My approach is near to D compiler's structure, that there are different stages
on the line from a thought to a binary code, that really works:
- planning... (contracts...)
- coding... (unittests...)
..
- syntax check
- semantic check
- compile (or translate and compile again on the target system)
- link (if needed)
- TEST&USE

IMHO
- The language's role to keep the programmer's fingers on the way to write
CLEAR, UNAMBIGOUS and UNDERSTANDABLE codes fast and efficiently.
- D could be a standard language to cover almost every projects where the target
compilers (for C?) exists.
- The fixed size of basic integral data types (or any types) in D is essential.
- The language should not depend on (rarely used) hardware solutions:
- stack mechanism
- addressing modes (and address arithmethics. No need for generalized near/far
handling. Who need it will write it.)
- word size
- blahblahblah
- The compilers of the target system should deal with HW dependencies.
- No need for dangerous C style pointer arithmetic
- Full controll over the garbage collector is essential (possibility of ROM
apps)
- In this very moment D has only one implementation, it supports Win32 on x86.
That is fine for start. Hopefully the generalized D to C translator (hopefully
opensourced :-) follows soon. We are waiting for it. It will solve almost all of
this problems.

And finally:
I vote on operator overloading, but I do not want to see it in any open sourced
standard library. It is fine to use, but hard to understand (or follow).
I vote on unions without additional houskeeping... It is useful for specialized
data storage but no need for storing pointers in it.
I vote on bit fields or controllable sized uniform integers. For unions only...

Best regards,

Tamas Nagy
MicroWizard Ltd.
Hungary
May 04 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
<MicroWizard ax.hu> wrote in message news:ab0k6c$2s8n$1 digitaldaemon.com...


 - The language should not depend on (rarely used) hardware solutions:
 - stack mechanism


So far I could only think of varargs... what other stack-dependencies
are there?


 - The compilers of the target system should deal with HW dependencies.


You mean, if word is 30 bits, the compiler should allocate two
words per int (which is always 32 bit)?


 - No need for dangerous C style pointer arithmetic


But still let it be there, for compatibility with C, and just
if somebody needs it for low-level tasks.


 - Full controll over the garbage collector is essential (possibility of


ROM

 apps)


It is there already.
May 04 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:ab0o22$30c4$1 digitaldaemon.com...

 <MicroWizard ax.hu> wrote in message


news:ab0k6c$2s8n$1 digitaldaemon.com...

 - The language should not depend on (rarely used) hardware solutions:
 - stack mechanism


 So far I could only think of varargs... what other stack-dependencies
 are there?


alloca() is supported <g>.
May 04 2002
prev sibling parent MicroWizard <MicroWizard_member pathlink.com> writes:
 - The language should not depend on (rarely used) hardware solutions:
 - stack mechanism


So far I could only think of varargs... what other stack-dependencies
are there?


Somebody mentioned that a PPC has only software stack solutions...
I was talking about these things. If there is a stack (I don't care
what kind of) the compiler should be able to use it as is.
Ex. a C compiler on a Z80 could use IX, IY base pointers, on an i8080 there are
no such things. M68000 has postincrement/predecrement addressing modes, 8086
hasn't. But all of them has C compilers roughly with the same capabilities,
except sizes, threads... I've seen the generated code of them and most compilers
inserts typical (but individual) sequences for "standard" operations.

It is a compiler implementation issue, not a language definition issue.


 - The compilers of the target system should deal with HW dependencies.


You mean, if word is 30 bits, the compiler should allocate two
words per int (which is always 32 bit)?


Yes and no. (The example of 30 bits sized word is not real nowadays :-)
There must be techniques in every compiler to handle standard data types else
this compiler implements only a part of D. No problem with that. (DOOM <-> ZX81)

Much more interesting things are the bus architecture (Harvard or Neumann), and
where are the data and the code stored, what size has the smallest data entity?
Bit, nibble, byte, word? ... These are important questions but only at the
compiler implementation. The language has possibilities to define exotic data
types and "standard" machanism to handle them. It is there and it is enough.
If I want to use strictly 12 bits words I have to suffer it and deserve it.


 - No need for dangerous C style pointer arithmetic


But still let it be there, for compatibility with C, and just
if somebody needs it for low-level tasks.


That is fine I agree. Like the dangerous unions. These are important ones.


 - Full controll over the garbage collector is essential ...


It is there already.


I know ;-)

With my letter I only wanted to stop an endless flame-like discussion... :-(
It didn't succeed ;-)))

Tamas Nagy
MicroWizard Ltd.
Hungary

microwizard ax.hu
May 05 2002
prev sibling parent reply "Mark T" <mt nospam.com> writes:
 - In this very moment D has only one implementation, it supports Win32 on


x86.

 That is fine for start. Hopefully the generalized D to C translator


(hopefully

 opensourced :-) follows soon. We are waiting for it. It will solve almost


all of

 this problems.


  people working on "Dfront" may want to look at:
http://smalleiffel.loria.fr/
SmallEiffel
Eiffel to C compiler

Is there a group doing something like this?  Or are they putting a D front
end on gcc (like GNAT for Ada)?
May 04 2002
parent fasa <tremon_r epita.fr> writes:
   people working on "Dfront" may want to look at:
 http://smalleiffel.loria.fr/
 SmallEiffel
 Eiffel to C compiler
 
 Is there a group doing something like this?  Or are they putting a D front
 end on gcc (like GNAT for Ada)?



No.


fasa
May 04 2002