Smooth transition to D2 for Tango users?

Bruce Adams tortoise_74 at yeah.who.co.uk
Sun Sep 21 18:30:36 PDT 2008


On Sun, 21 Sep 2008 21:13:04 +0100, Denis Koroskin <2korden at gmail.com>  
wrote:
>
> I would like to show some other aspect of the issue.
>
> D has support for inline assembly. Different processors might have  
> different assembly syntax and it is unlikely that every future D  
> compiler would support all the syntaxes and recognize all command. Take  
> a look at the tango.core.Atomic module. It contains x86 and x64 assembly  
> instructions so far. However, it is likely that implementation for other  
> platforms will be added soner or later (ARM, PowerPC and others). And  
> they should somehow co-exist in one source code, like this:
>
> bool cas(ref int value, int newValue, int oldValue) {
>    version (X86) {
>      asm {
>        mov EDX, newValue;
>        mov EAX, oldValue;
>        mov ECX, value;
>        lock;
>        cmpxchg [ECX], EDX;
>        setz AL;
>      }
>    } else version (PowerPC) {
>      asm {
>        // an implementaion using load-linked/store-conditional
>      }
>    }
> }
>
> (I am no expert in assembly, so I copied x86 code and left ppc code  
> blank :)).
>
> Current parsing rules state that the code in version block should be  
> semantically correct, even if it is ignored. But since DMD knows  
> basically nothing about those ll/sc op-codes, the code can't be placed  
> in one source file, which is bad for maintainability.
>
> Besides, I foresee "Smoth D2 to D3 transition", "Smooth D3 to D4  
> transition" etc topics in future, so we should solve the issue once and  
> for all.

The inline assembly and language variant cases both demonstrate there are  
at minimum 2
incompatible use cases for the version statement. The language currently  
only supports
the case where the code is syntactically correct for all versions. Though  
if the alternate
assembly versions work in Tango there must already be a special case that  
asm blocks are
ignored outside the currently active version.
To handle it on the language/compiler side two things are required.
  1) a way to indicate the differences between the two kinds of version  
block
  2) a way to handle 'non'-parsing blocks.
I don't think its unreasonable to expect that braces will be balanced in  
all future versions of the
language. So a compiler could re-synchronise following the next balanced  
code brace. The tokeniser will
choke on unidentified keywords unless they are parsed as strings and  
ignored rather than producing an
unknown token. The lexer is going to have to know enough to handle braces  
and detect braces that do not
apply because they are within strings or comment whatever. It would take a  
lot of care to get right.
However its done, compiler, preprocessor or whatever its going to be a bit  
yucky somewhere. Maybe a
different kind of bracket would make things easier. Say version @{  /*  
don't parse me */ @}, though that's
dangerously close to #endif :). I cant' help thinking the safest thing is  
some kind of source 2 source translator.
D1 to D2 would help ease the transition greatly but result in a lot of  
crappy quality D2 code out there.
D2 to D1 might be a bigger project but possibly more useful.
I previously suggested annotatations as they might simplify the  
implementation of a converter significantly. They
could be deprecated as time went on and the project grew more mature.
But what do I know, I'm just tha window cleaner :-)



More information about the Digitalmars-d mailing list