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