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

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

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

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

>   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

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