On 10/15/2010 01:49 PM, Max Samukha wrote:
> Go has even gone (sorry) as far as allocating copies *every* time the
> address of a local is taken.

I may be mistaken on that.

On 2010-10-15 04:49:19 -0400, Max Samukha <spambox@d-coding.com> said:

> static S s;
> ref S foo()
> {
>      return s;
> }

Pointers are allowed in SafeD; pointer arithmetic is not. Taking the address of a static or global variable should be allowed. If this doesn't compile, you should report it a bug:

	static S s;
	S* foo()
	{
		return &s;
	}

There's nothing unsafe about taking the address of a static or global variable since the pointer can never outlive the variable.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Paulo Pinto:

> Still most modern languages are moving away from inline assembly.

Inline assembly is good to learn and teach assembly programming too :-)

Today a good system language needs to be designed to minimize the need of inline asm (see D vector ops), but it's a good thing to have as fall-back. I'd like the asm expressions & the pragma(allow_inline), of ldc.

Bye,
bearophile

On 10/15/2010 02:14 PM, Michel Fortin wrote:
> On 2010-10-15 04:49:19 -0400, Max Samukha <spambox@d-coding.com> said:
>
>> static S s;
>> ref S foo()
>> {
>> return s;
>> }
>
> Pointers are allowed in SafeD; pointer arithmetic is not. Taking the
> address of a static or global variable should be allowed. If this
> doesn't compile, you should report it a bug:
>
> static S s;
> S* foo()
> {
> return &s;
> }
>
> There's nothing unsafe about taking the address of a static or global
> variable since the pointer can never outlive the variable.
>

Ok, makes sense.

Sounds like violent agreement to me.

Andrei

On 10/15/10 4:17 CDT, Paulo Pinto wrote:
> Still most modern languages are moving away from inline assembly.
>
> Even Microsoft has dropped inline assembly support for the 64bit version of
> Visual C++, pointing
> developers to MASM.
>
> People will always complain no matter what. Just use the official assembler
> for the target platform.
>
> Personally the last time I used inline assembly I was still target MS-DOS,
> long time ago and actually
> it is one of the features I don't like in D.
>
> --
> Paulo
>
> "Walter Bright"<newshound2@digitalmars.com>  wrote in message
> news:i98ub5$2bk7$1@digitalmars.com...
>> Yeah, and I've done that. It doesn't work out as well as you say, nor is
>> it that easy. Problems:
>>
>> 1. You have to reimplement it for every platform and every memory model.
>> 2. For some systems, like Windows, there are a wide variety of assemblers.
>> They all use slightly different syntax. Distributing an asm file means an
>> *unending* stream of complaints from people who don't have an assembler or
>> have a different one than yours.
>> 3. Getting all the boilerplate segment declarations right is a nuisance.
>> 4. Name mangling.
>> 5. Next your asm code all breaks when you want to recompile your app as a
>> shared library.
>> 6. Asm files are a nightmare on OSX.
>>
>> A language should be there to solve problems, not create them :-)
>>
>> Paulo Pinto wrote:
>>> Easy, just implement a small assembly funtion.
>>>
>>> Not everything has to be in the language.
>>>
>>> "Walter Bright"<newshound2@digitalmars.com>  wrote in message
>>> news:i984lr$odj$3@digitalmars.com...
>>>> Walter Bright wrote:
>>>>> It's hard to see how to implement, say, a storage allocator with no
>>>>> pointer arithmetic.
>>>> Here's another one. Try implementing va_arg without pointer arithmetic.
>>>
>

And to be abused as well.

I still remember having seen a C++ program in the MS-DOS days, where the
only C++ feature
was main() and the other function names. All function bodys were inline
assembly.

The developer had used the C++ compiler as a poor man's assembler.

I would rather not see such type of code in D.

Not to mention that it makes portability even worse. So besides having to
have several #ifdefs for
different OS, you also need to have for different processor architectures.

Is D inline assembly supporting all x86 instruction set? What processors besides x86 are supported?

If I have to drop out to a real assembler for certain opcodes, then the gain
of inline assembly is anyway
lost.

--
Paulo

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:i99d48$9mj$1@digitalmars.com...
> Paulo Pinto:
>
>> Still most modern languages are moving away from inline assembly.
>
> Inline assembly is good to learn and teach assembly programming too :-)
>
> Today a good system language needs to be designed to minimize the need of inline asm (see D vector ops), but it's a good thing to have as fall-back. I'd like the asm expressions & the pragma(allow_inline), of ldc.
>
> Bye,
> bearophile

On 10/14/10 17:06 CDT, bearophile wrote:
> Found through Reddit, talk slides by Rob Pike, "The Expressiveness of Go":
> http://go.googlecode.com/hg/doc/ExpressivenessOfGo.pdf
>
> http://www.reddit.com/r/programming/comments/dr6r4/talk_by_rob_pike_the_expressiveness_of_go_pdf/

It's a good deck I think. I made a comment on reddit:

http://www.reddit.com/r/programming/comments/dr6r4/talk_by_rob_pike_the_expressiveness_of_go_pdf/c12dkde


Andrei

Paulo Pinto wrote:
> Still most modern languages are moving away from inline assembly.

It's a pain to write an inline assembler and figure out how to integrate it in with the rest of the compiler. I can see why compiler writers don't want to do it, and look for reasons not to.

Most modern languages do not even generate code - they target the JVM or CLI.


> Even Microsoft has dropped inline assembly support for the 64bit version of Visual C++, pointing
> developers to MASM.

I'd be curious as to their rationale.


> People will always complain no matter what. Just use the official assembler for the target platform.

Microsoft MASM has about 30 different incarnations, all accepting different syntax.

It's a *constant* source of grief for customer support.


> Personally the last time I used inline assembly I was still target MS-DOS, long time ago and actually
> it is one of the features I don't like in D.

I'd be forced to write a standalone assembler if D didn't have inline assembler.

In any case, inline assembler in D is a substantial productivity booster for me for anything that needs assembler. The inline assembler is also quite ignorable, if you don't like it.

Max Samukha wrote:
> On 10/15/2010 12:32 PM, Walter Bright wrote:
>>
>> The example relies on taking the address of a ref in a safe function. To
>> close this hole, it appears that should be disallowed.
> 
> And disallowing it makes references not so useful.

I don't see why. They're useful enough.


> What I like about Go's solution is that it is consistent with closures. When a group of locals escape with a closure (that is when the address of the local function using that group is taken) they are copied to heap. When a local escape by ref (that is when the address of the local is taken), it is also copied to heap.

I understand how it works. There is a downside to it, though. In D2, closures get copied to the GC heap if there is a possibility of an escaping reference. A lot of people complain about this being unexpected hidden overhead.

The trouble with "copy any ref'd local to the heap" automatically happening is the biggest advantage of passing by ref (efficiency) is automatically lost. Even if it does not escape, it is copied to the heap anyway, as you point out below.


> What I don't like about Go's closures/addresses-to-locals and D's delegates is that stuff is heap-allocated implicitly and by default. Go has even gone (sorry) as far as allocating copies *every* time the address of a local is taken.

Exactly. (Though D won't do the copy if it can prove that the delegate does not escape.)


> That reminds me of the argument about "new" being necessary for classes because it makes the heap allocation explicit. It is difficult to say good-bye to "new" but at the same time we are somehow happy with implicitly allocated closures.

I think that implicitly allocated closures are a lot less common than passing a local by reference.

Max Samukha wrote:
> On 10/15/2010 01:49 PM, Max Samukha wrote:
>> Go has even gone (sorry) as far as allocating copies *every* time the
>> address of a local is taken.
> 
> I may be mistaken on that.

It would require a rather sophisticated compiler to be able to not do that.