Nick Sabalausky wrote:
> "Nick Sabalausky" <a@a.a> wrote in message news:isoltk$1ehd$1@digitalmars.com...
>> "Don" <nospam@nospam.com> wrote in message news:isoh6c$15jb$1@digitalmars.com...
>>> Nick Sabalausky wrote:
>>>> So my main question: Does DMD do anything like, say, detecting the CPU at compile time and then enabling instructions only available on that CPU and up? Or does it do anything like always assuming the target CPU has SSE2? Anything like that that could cause differences between our CPUs to result in object code that will work on one of the CPUs, but not the other? FWIW, the CPU on my linux box is i686, so it's not like I'm on some super-ultra-old i586, or anything like that.
>>> DMD itself doesn't, but the array operations do. The DMD backend is ancient, and generates code for original Pentiums (+ 64 bit equivalents of the same instructions).
>> Is there any way to force the array operations down to a certain level? Or even better yet, have them detect the CPU at startup and then use the appropriate version?

The runtime detects the CPU type at startup, and uses SSE/SSE2 if available, otherwise falls back to x87.
The 64-bit DMD doesn't use SSE2 at all, yet.

> It would be a bad thing if we can't use an SSE2 CPU to compile a binary that'll work on a non-SSE2 machine.
Indeed.

"Andrew Wiley" <wiley.andrew.j@gmail.com> wrote in message news:mailman.762.1307693296.14074.digitalmars-d-learn@puremagic.com...
> On Thu, Jun 9, 2011 at 5:58 PM, Nick Sabalausky <a@a.a> wrote:
>
>> "Bernard Helyer" <b.helyer@gmail.com> wrote in message news:isdgdc$m3a$1@digitalmars.com...
>> > If you run the program in GDB, can you disassemble when the error is
>> > given? That may give you the instruction the kernel is assasinating
>> > your
>> > process for.
>>
>> I can try that if anyone can help walk me through it or at least point me
>> to
>> a good beginner's tutorial for gdb. I never use commandline debuggers,
>> and
>> I've never even touched gdb, so I don't have the slightest clue how to
>> use
>> it.
>>
>>
>> The short version is to run `gdb yourapp` which will get you into the GDB
> shell. Then `run` to actually start the app. It will halt and return to
> the
> shell when it hits the bad instruction, and you should type `disass` to
> view
> the assembly code of the current function. There will be a pointer (->, I
> think) pointing to the current instruction in the listing.
> You can find GDB basics at http://www.cs.cmu.edu/~gilpin/tutorial/
> although
> that tutorial doesn't include `disass`. I mostly learned it by firing it
> up
> and typing `help`  :D
>

Thanks. This is what I get:

$ gdb ./dvm-0.2.0-linux-32
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/nick/dev/d/tool/dvm-0.2.0-linux-32...(no
debugging symbols found)...done.
(gdb) run
Starting program: /home/nick/dev/d/tool/dvm-0.2.0-linux-32
[Thread debugging using libthread_db enabled]

Program received signal SIGILL, Illegal instruction.
0x080bccdb in
_D5tango4core4sync6Atomic31__T13memoryBarrierVb1Vb0Vi0Vb0Z13memoryBarrierFZv
()
(gdb) disass
Dump of assembler code for function
_D5tango4core4sync6Atomic31__T13memoryBarrierVb1Vb0Vi0Vb0Z13memoryBarrierFZv:
   0x080bccd8 <+0>:     push   %ebp
   0x080bccd9 <+1>:     mov    %esp,%ebp
=> 0x080bccdb <+3>:     lfence
   0x080bccde <+6>:     pop    %ebp
   0x080bccdf <+7>:     ret
End of assembler dump.
(gdb)

So apperently it's a memory fence instruction. I don't have a clue what my CPU supports in that area. Oh, and apperently it's inside Tango, so maybe I'll bring this up over there. But I have no idea if that's something that Tango has in common with druntime or not.