Mike writes:
> On Wednesday, 10 February 2016 at 17:03:35 UTC, Dan Olson wrote:
>>
>> I noticed that even thumb-1 has different instruction set based on
>> arm architecture.
>
> Yes. I did a little more research into this, as it peeked my
> curiosity.
Good info
Mike writes:
> I think to do this properly with ARM you need to consider the ARM
> architecture (ARMv6, ARMv7, ARMv7-A, ARMv7-M, etc..) AND the
> instruction set (ARM or ARM_Thumb). I read it somewhere, but I'm
> having trouble finding it again.
>
> Anyway, used in conjunction with the architectu
Timo Sintonen writes:
> Thumb2 is an extension to thumb. It has everything that thumb has and
> more. There is nothing in thumb that is not in thumb2. There is no
> thumb1. Thumb is sometimes called thumb1 because thumb is often
> understood to be both thumb and thumb2.
>
> Thumb2 was introduced t
Hi Iain, Johannes. I'm asking here because I don't expect anybody else
is playing with thumb instructions.
Both GDC and LDC have version ARM_Thumb defined for original thumb (call
it thumb-1) and thumb-2. But there is no way to tell in D code which
set is supported.
GCC and clang define these:
Seems to be working good now. Unittests for druntime all pass so Fiber
switching code is working. Unittests for phobos fails in biguintcore,
but I don't suppose that is an OS X specific thing.
Iain, I am going to make separate pull requests for each OS X topic
(fibers, symbol mangling, gc data s
"Iain Buclaw via D.gnu" writes:
> On 6 June 2015 at 18:54, Dan Olson via D.gnu
> wrote:
>
> "Iain Buclaw via D.gnu" writes:
>
> > Alas, after looking at backend, it turns out that the answer is
> no.
> >
"Iain Buclaw via D.gnu" writes:
> Alas, after looking at backend, it turns out that the answer is no.
>
> In the glue sources (d-decls.cc), replace 'set_user_assembler_name'
> with 'SET_DECL_ASSEMBLER_NAME' and rebuild the module without your
> workaround.
Ok, that works for data. Functions (st
"Iain Buclaw via D.gnu" writes:
> On 5 June 2015 at 08:40, Dan Olson via D.gnu
> wrote:
>>
>> Sorry for a long chain on OSX. But one last unresolved symbol from
> make
>> check-d: "_d_osx_image_init". Is it just a placeholder or is it
> hidden
"Iain Buclaw via D.gnu" writes:
> On 5 Jun 2015 08:05, "Dan Olson via D.gnu"
> wrote:
>
> That's interesting, it should do that for you automatically, there
> should be only one reason why that doesn't happen, and I don't use it
> for
"Iain Buclaw via D.gnu" writes:
> I hope I'm not shying you away by saying, this is what someone needs
> to find out.
No, not at all. I've gotten pretty used to puzzling through TLS
implementations for LDC porting.
> I'd first suggest to build gcc only and test what is outputted. Use a
> test p
Sorry for a long chain on OSX. But one last unresolved symbol from make
check-d: "_d_osx_image_init". Is it just a placeholder or is it hidden
somewhere. Does gdc still need the code to set setup gc scanning? How
is TLS on OSX? - if not ready, would emutls work?
--
Dan
Dan Olson writes:
> Looks like I need to track down missing symbols from rt.tlsgc now. I
> think it is becoming a fun puzzle :-) The arm stuff can wait.
How do I tell gdc that OS X needs target specific underscore "_" prefix
added to pragma(mangle, name)
Dan Olson writes:
> "Iain Buclaw via D.gnu" writes:
>
>> On 4 June 2015 at 17:33, Dan Olson via D.gnu
>> wrote:
>>
>> As a sanity step before switching to gcc-6, tried to build gdc-5
>> branch
>> on OSX X86_64
"Iain Buclaw via D.gnu" writes:
> On 4 June 2015 at 17:33, Dan Olson via D.gnu
> wrote:
>
> As a sanity step before switching to gcc-6, tried to build gdc-5
> branch
> on OSX X86_64 with gcc-5.1. I must be missing something because no
> vers
"Iain Buclaw via D.gnu" writes:
> All PRs should be based on master, and they get trickled down to
> release branches as needed.
>
> Master only works (or at least, has been tested) with the development
> snapshot listed in gcc.version. Which would be version gcc-6 now.
Ok, thanks.
As a sanity
ketmar writes:
> On Thu, 04 Jun 2015 00:15:37 -0700, Dan Olson wrote:
>
>> Starting a pull request for ARM and grabbed gdc master, but not sure
>> what gcc it likes. I tried gcc-5.1 but
>>
>> $ ./setup-gcc.sh ../gcc-5.1.0 found gcc version 5 This version
Starting a pull request for ARM and grabbed gdc master, but not sure
what gcc it likes. I tried gcc-5.1 but
$ ./setup-gcc.sh ../gcc-5.1.0
found gcc version 5
This version of GCC (5) is not supported.
--
Dan
Dan Olson writes:
> Dan Olson writes:
>
>> Johannes Pfau writes:
>>>
>>> _Dmodule_ref?
>>> You can just declare it as extern(C) __gshared void* _Dmodule_ref; (But
>>> IIRC you have to compile with -nophoboslib to make it work)
>>> It&#x
Iain Buclaw writes:
>
> Doesn't Apple forbid any language except Objective-C ? Or is that a
> misguided fallacy of mine? (Objective D, anyone? :-)
I think it once was so, but no longer.
http://stackoverflow.com/questions/3949995/what-programming-languages-can-one-use-to-develop-iphone-ipod-touc
Dan Olson writes:
> Johannes Pfau writes:
>>
>> _Dmodule_ref?
>> You can just declare it as extern(C) __gshared void* _Dmodule_ref; (But
>> IIRC you have to compile with -nophoboslib to make it work)
>> It's used by the runtime/compiler to setup th
Johannes Pfau writes:
>
> _Dmodule_ref?
> You can just declare it as extern(C) __gshared void* _Dmodule_ref; (But
> IIRC you have to compile with -nophoboslib to make it work)
> It's used by the runtime/compiler to setup the ModuleInfos but you
> don't have to initialize it, it just needs to be de
Jacob Carlborg writes:
>
> Cool, I'm really looking forward to this. How did it go with the simulator?
D for the iphone simulator worked without changes to gcc-4.8 src since
it targets i686 darwin fine. To get it to work it was more of finding
the right config recipe. I did have to use my drunt
Ok, D is not there yet, but I managed to build a crippled gcc-4.8 (with
D) targeting arm-apple-darwin and I can compile simple C functions to .o
files and link them into an iphone app. And run it on my iphone. The D
and C++ compilers built, but I have probably a potpourri of issues since
I gave 4
Johannes Pfau writes:
>
> Yes. The GC needs special runtime / compiler support to scan TLS
> variables and this code has traditionally been buggy / difficult to
> implement.
>
> You can use a simple test to detect the most obvious errors:
I used your test, but had to make a bunch of objects to ge
So far I am having fun gradually pushing D into apple ios sim (it runs
i386 not arm). I am curious though about thread local storage and GC.
I saw older posts about it being an issue and have not seen anything
more on it. Is it still an issue? I am doing all this with latest D
git and gcc-4.8-20
Is somebody working the osx issues with the latest git gdc + gcc4.8? I
muddled through a few druntime compile and link problems (related to
rt/memory_osx.d - noted by previous posters) and am able to compile -n-
run a couple test programs. But since the areas in question deal with
TLS, EH, and GC
Jacob Carlborg writes:
> Cool, I also tried this, with DMD tough. I didn't get very far, there
> are functionality that DMD needs that's missing from the iPhone SDK.
Jacob, how far did you get?
A couple years ago I started building a bare druntime. Not too useful
because I stripped GC and with
I am coming back to D fun after a year. I am playing on osx 10.6 and just
built native gdc last weekend using github gdc-4.7.
Sorry if this has been discussed before, but my searches could not find
it. I discovered that dmd and gdmd -lib behave different. I really like
the way dmd -lib option wo
28 matches
Mail list logo
