<div dir="ltr">Hi Sverker.<div><br></div><div>I want to look at the bad performance issue you observed with respect to passing "struct{int}" as a parameter vs just passing "int".  I wrote a tiny test program to observe the assembly generated by gcc and the code for the two cases looked identical.  Also, some research into calling conventions hasn't offered me any explanations yet.</div>
<div><br></div><div>Do you have any details you can share that will help me understand when and why performance degrades?</div><div><br></div><div>I want to understand because I am looking at a struct{int} approach as part of a C++ nif solution, and I am very sensitive about adding bloat.</div>
<div><br></div><div>Thanks,</div><div>Dan.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 7, 2014 at 12:46 PM, Sverker Eriksson <span dir="ltr"><<a href="mailto:sverker.eriksson@ericsson.com" target="_blank">sverker.eriksson@ericsson.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>Thanks for the patch.<br>
      <br>
      I got one objection/question though. My C++ knowledge is a bit
      rusty but as I understand it<br>
      the "enum class" construct demands that Type is an integer type.<br>
      <br>
      This is currently true for ERL_NIF_TERM but it might not be in the
      future.<br>
      I earlier tried to define ERL_NIF_TERM as<br>
      <br>
      typedef struct { int x; } ERL_NIF_TERM;<br>
      <br>
      to get stronger type checking even for C. I reverted that due to
      bad performance<br>
      as gcc has different calling conventions for int and struct {int}.
      However, future compilers<br>
      might be better at passing struct{int} by value in which case we
      might want to change<br>
      the definition of ERL_NIF_TERM.<br>
      <br>
      What then? Do we ignore CUSTOM_NIF_TERM_TYPE in such a scenario?<br>
      <br>
      <br>
      /Sverker, Erlang/OTP<div><div class="h5"><br>
      <br>
      <br>
      On 02/07/2014 06:34 PM, Daniel Goertzen wrote:<br>
    </div></div></div>
    <blockquote type="cite"><div><div class="h5">
      <pre>When writing NIFs in C++, it is impossible to employ C++ function
overloading because the underlying type of ERL_NIF_TERM is "unsigned int".
For example:

// won't compile :(
#include <erl_nif.h>
void my_func(ERL_NIF_TERM a)  {...}
void my_func(unsigned int a)  {...}


This patch allows NIF authors to mutate the type of ERL_NIF_TERM by
defining the macro CUSTOM_NIF_TERM_TYPE().  In the example below, the
underlying unsigned integer type gets wrapped as a C++11 typed
enumeration.  The type of ERL_NIF_TERM is now unique and can be used in
overloaded functions.

// compiles!  :)
#define CUSTOM_NIF_TERM_TYPE(Type) enum class ERL_NIF_TERM : Type {};
#include <erl_nif.h>
void my_func(ERL_NIF_TERM a)  {...}
void my_func(unsigned int a)  {...}


The patch has no impact on erl_nif.h if CUSTOM_NIF_TERM_TYPE is not defined
(other than flipping the definition order of ERL_NIF_TERM and ERL_NIF_UINT).

A similar approach has been used on my C++11 NIF wrapper (
<a href="https://github.com/goertzenator/nifpp" target="_blank">https://github.com/goertzenator/nifpp</a>).  The wrapper requires manual
installation of a similar patch, and I would love to remove that
requirement.

Regards,
Dan.

</pre>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><pre>_______________________________________________
erlang-patches mailing list
<a href="mailto:erlang-patches@erlang.org" target="_blank">erlang-patches@erlang.org</a>
<a href="http://erlang.org/mailman/listinfo/erlang-patches" target="_blank">http://erlang.org/mailman/listinfo/erlang-patches</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div>