[m-rev.] for review: deconstruct.named_arg for java

[Ian MacLarty]

On Mon, Jul 5, 2010 at 3:57 PM, Julien Fischer
<juliensf at csse.unimelb.edu.au> wrote:
>
> On Mon, 5 Jul 2010, Ian MacLarty wrote:
>
>> On Mon, Jul 5, 2010 at 2:04 PM, Ian MacLarty
>> <maclarty at csse.unimelb.edu.au> wrote:
>>>
>>> On Fri, Jul 02, 2010 at 05:43:49PM +1000, Julien Fischer wrote:
>>>>
>>>> On Fri, 2 Jul 2010, Ian MacLarty wrote:
>>>>
>>>>> On Fri, Jul 2, 2010 at 3:58 AM, Julien Fischer
>>>>> <juliensf at csse.unimelb.edu.au> wrote:
>>>>>>
>>>>>> On Wed, 30 Jun 2010, Peter Wang wrote:
>>>>>>
>>>>>>> Branches: main
>>>>>>
>>>>>> Is there any reason not to include this on the 10.04 branch?
>>>>>>
>>>>>
>>>>> I can think of one:  it will delay the release even further.  If we're
>>>>> going to change to a 6 monthly release cycle, we need to *not* add new
>>>>> features to the release branch.  New features can go in the next
>>>>> version.
>>>>
>>>> This one won't delay the release, and I think the more of the stdlib
>>>> that 10.04 supports in the java (and erlang) grade(s) the better.
>>>>
>>>>> BTW is there anything holding up the release at the moment?
>>>>
>>>> Ideally, I wanted to improve the documentation in the user's guide for
>>>> mmc --make, but it looks like I won't have time before I head overseas.
>>>> (So, that can go into 10.04.1)
>>>>
>>>> In my view the remaining tasks for 10.04 are:
>>>>
>>>> * I want to sort out this issue with source distribution (bug #115)
>>>>   that came up the other day.  (There is a workaround in place, but I am
>>>>   currently testing a proper fix.)
>>>>
>>>> * Bug #153 needs to be looked at.
>>>>
>>>> * I have a reference manual change that documents MR_word_to_float and
>>>>   friends that nees to go in.  (I also have an addition to
>>>>   samples/c_interface that provides a more thorough illustration of the
>>>> C
>>>>   data passing conventions.)
>>>>
>>>> * I think we really need some examples of how to use the Java and Erlang
>>>>   interfaces, in samples/java_interface and samples/erlang_interface.
>>>>
>>>> * zs is unhappy about the number of warnings that are generated by gcc
>>>>   when compiling things in asm_fast.  (We should identify what is going
>>>>   on here at least.)  (Someone suggested grepping the warnings out, but
>>>>   I don't see how you can do that with mmc --make -- particularly on
>>>>   systems that don't have grep!)
>>>>
>>>
>>> What seems to be happening is that functions are being declared with
>>> a prototype like the following:
>>>
>>>    static void mercury__tree234__LCMCpr_insert2_1_4_0(void)
>>> __asm__("_entry_" "mercury__tree234__LCMCpr_insert2_1_4_0")
>>>
>>> and then being referred to without being defined in C code.
>>> The functions are in fact defined using assembly code.
>>>
>>> It seems to be the fact that the function is declared static that is
>>> causing gcc to expect a definition of the function in the same file.
>>> Removing the static keyword appears to fix the problem.
>>>
>>> Here is the hack I used to test this:
>>>
>>> Index: runtime/mercury_goto.h
>>> ===================================================================
>>> RCS file: /home/mercury1/repository/mercury/runtime/mercury_goto.h,v
>>> retrieving revision 1.54
>>> diff -u -r1.54 mercury_goto.h
>>> --- runtime/mercury_goto.h      4 Dec 2009 02:39:47 -0000       1.54
>>> +++ runtime/mercury_goto.h      5 Jul 2010 03:52:05 -0000
>>> @@ -877,7 +877,7 @@
>>>     #define MR_declare_entry(label)                                    \
>>>        extern void label(void) __asm__("_entry_" MR_STRINGIFY(label))
>>>     #define MR_declare_static(label)                                   \
>>> -       static void label(void) __asm__("_entry_" MR_STRINGIFY(label))
>>> +       void label(void) __asm__("_entry_" MR_STRINGIFY(label))
>>>     #define MR_define_extern_entry(label)      MR_declare_entry(label)
>>>     #define MR_define_entry(label)                                     \
>>>                MR_ASM_ENTRY(label)                                     \
>>>
>>> I ran nm on tree234.o before and after this change and there was no
>>> difference, so this change doesn't seem to cause extra symbols to be
>>> exported.
>>>
>>
>> In fact the .o files are byte-for-byte equivalent with/without the
>> static keyword.
>
> Is this still the case if you disable the C compiler optimizations, e.g.
> compile with gcc -O0?  If it's not, then does the number of symbols
> exported from the object file increase in the case where you removed
> the static?
>

At -O0 the files are still equivalent.

Ian.

--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------