Calling convention for ASM on Linux AMD64
What calling convention is used for assembly language in Linux
AMD64?
Normally the parameters go in fixed order into designated
registers.
import std.stdio;
// Linux AMD64
float* test(float *x,ulong y){
asm{
naked;
align 16;
mov RAX,RDI;
ret;
}
}
void main(){
float[] f=new float[16];
writeln([0]);
float* a=test([0],7);
writeln(a);
}
If the ulong y parameter is removed from the function definition
the pointer x goes into RDI as expected. When y is added it all
goes wrong. According to AMD64 the pointer should stay in RDI and
the ulong go into RSI.
Re: Load D shared library on windows x64
On Friday, 17 August 2018 at 20:27:05 UTC, Tofu Ninja wrote:
Its this part that fails... always returns null
HMODULE h = cast(HMODULE) Runtime.loadLibrary(dllName);
if (h is null) {
writeln("error loading");
return;
}
I there any way to see why Runtime.loadLibrary is failing? It
just returns null on error which is not very helpful.
Re: Set optional function parameter
On Friday, August 17, 2018 2:52:53 AM MDT Andrey via Digitalmars-d-learn
wrote:
> Hello,
>
> In D there is a nice function:
> > auto Tuple!(int,"status",string,"output") executeShell (
> >
> > scope const(char)[] command,
> > const(string[string]) env = cast(const(string[string]))null,
> > Config config = cast(Config)0,
> > ulong maxOutput = 18446744073709551615LU,
> > scope const(char)[] workDir = null,
> > string shellPath = nativeShell()
> >
> >) @trusted;
>
> It has got 5 optional parameters. For example I want set only the
> fifth and all other leave with default values.
>
> If it was C/C++ then I would write:
> > executeShell("my_command", nullptr, 0, 18446744073709551615,
> > nullptr, "my/path");
>
> Long and boring...
>
> What about D? Does it support something like this:
> > executeShell("my_command", shellPath = "my/path");
>
> or
>
> > executeShell("my_command", default, default, default, default,
> > "my/path");
>
> I mean - can I skip some arguments and set only one that I want?
> Hm, Python, it seems to me, support this feature.
The short answer is no.
D is more like C++ or Java in this respect. Python has named arguments,
which allow you to indicate which parameter an argument goes with by name
rather than by position, thus allowing you to skip giving values for some
parameters if they have default values, whereas most C-derived languages -
including D - do not have such a feature.
Usually, it's a non-issue, because having more than one - maybe two
- default arguments is pretty rare, and having long parameter lists is
usually considered bad design. Unfortunately, executeShell is one of the few
cases in Phobos where a function has quite a few parameters, and D does not
directly provide a way to skip any parameters when providing arguments so
that you can provide a value for an argument later in the parameter list
while not providing parameters earlier in the list.
There have been some templated solutions floating around from time to time
to allow folks to implement a form of named arguments themselves, but as
I've never done anything with them, I don't know if they're designed to help
you in a situation like this or if they're designed such that the person who
writes the function can give you a way to use named arguments with that
particular function. You may find something floating around on
code.dlang.org that would help you.
However, if you're calling executeShell more than once, you could simply
create a wrapper function that only had the parameters you wanted and then
passed the full list of arguments to executeShell.
- Jonathan M Davis
Re: Load D shared library on windows x64
Its this part that fails... always returns null
HMODULE h = cast(HMODULE) Runtime.loadLibrary(dllName);
if (h is null) {
writeln("error loading");
return;
}
Load D shared library on windows x64
Do shared libraries work? I am trying to load a D library into a
D program but Runtime.loadLibrary just returns null for me and I
am not sure what I am doing wrong.
import std.stdio;
import std.file : exists, getcwd, rename;
import core.thread;
import std.conv : to;
version(tofu_dynamic){
import core.sys.windows.windows;
import core.runtime;
pragma(msg, "Dynamic Link Library");
HINSTANCE g_hInst;
export extern (Windows) BOOL DllMain(HINSTANCE hInstance, ULONG
ulReason, LPVOID pvReserved) {
switch (ulReason) {
case DLL_PROCESS_ATTACH:
writeln("DLL_PROCESS_ATTACH");
Runtime.initialize();
break;
case DLL_PROCESS_DETACH:
writeln("DLL_PROCESS_DETACH");
Runtime.terminate();
break;
case DLL_THREAD_ATTACH:
writeln("DLL_THREAD_ATTACH");
return false;
case DLL_THREAD_DETACH:
writeln("DLL_THREAD_DETACH");
return false;
default:
}
g_hInst = hInstance;
return true;
}
pragma(mangle, "rti_start") export void rti_start(){
writeln("rti start :)");
}
} else {
void main(string[] args) {
uint id = 0;
while(true) {
if(exists("graph.dll")){
auto name = "rti." ~ id.to!string ~ ".dll";
rename("graph.dll", name);
id++;
loadLib(name);
}
Thread.sleep(dur!("seconds")(1));
}
}
static void loadLib(string dllName) {
import core.sys.windows.windows;
import core.runtime;
Thread.sleep(dur!("seconds")(1));
writeln("Start Dynamic Link to ", dllName, "...");
HMODULE h = cast(HMODULE) Runtime.loadLibrary(dllName);
if (h is null) {
writeln("error loading");
return;
}
scope(exit){
if (!Runtime.unloadLibrary(h))
writeln("error freeing dll");
}
FARPROC fp = GetProcAddress(h, "rti_start");
if (fp is null) {
writeln("error loading symbol rti_start");
return;
}
auto fun = cast(void function()) fp;
fun();
writeln("End...");
}
}
Re: How to declare static compile-time assoc array inside struct?
On Friday, August 17, 2018 9:59:18 AM MDT Steven Schveighoffer via Digitalmars-d-learn wrote: > On 8/13/18 9:21 AM, Andrey wrote: > > On Monday, 13 August 2018 at 11:53:06 UTC, rikki cattermole wrote: > >> You must use a module constructor to initialize it. > > > > Tried this: > > static this() > > `shared static this()` > > normal static this runs on every thread creation, and so cannot modify > immutable data. Well, it's not _supposed_ to be able to modify immutable data. It's a long-standing bug that the compiler allows you to initialize immutable variables in non-shared, static constructors, and if you do it, it's going to reinitialize it in each thread, which is definitely not good, but for whatever reason hasn't managed to be enough of a priority to get fixed. https://issues.dlang.org/show_bug.cgi?id=4923 So, unfortunately, it's currently up to the programmer to get it right, and they won't get an error when they screw it up. - Jonathan M Davis
Re: How to declare static compile-time assoc array inside struct?
On 8/13/18 9:21 AM, Andrey wrote: On Monday, 13 August 2018 at 11:53:06 UTC, rikki cattermole wrote: You must use a module constructor to initialize it. Tried this: static this() `shared static this()` normal static this runs on every thread creation, and so cannot modify immutable data. -Steve
Re: Array!bool -> Chunks -> foreach: out of bounds
On Wednesday, 15 August 2018 at 18:27:56 UTC, Steven Schveighoffer wrote: PR: https://github.com/dlang/phobos/pull/ -Steve Thank you for looking into this one. Regards, Elias
Re: ?? How to subscribe to Multicast Broadcasts ??
On 8/12/18 9:12 PM, Joe wrote:
Hello All!
I've been trying every possible combination and cannot get anything
working. (>_<)
This is I think the closest I've got, I think the problem may be with
the 3 argument. I'm not sure how to join the Multicast IP membership?
(this code currently does not work - throws error:
'Unable to set socket option: An invalid argument was supplied'.)
Socket listen_socket = new Socket(AddressFamily.INET, SocketType.DGRAM,
ProtocolType.UDP);
listen_socket.setOption(SocketOptionLevel.IGMP,
SocketOption.IPV6_JOIN_GROUP, 1);
auto adr = getAddress("0.0.0.0", "56000");
listen_socket.bind(adr[0]);
This is how the messages are sent (which works fine):
Socket udp_broadcast_soc = new UdpSocket();
udp_broadcast_soc.setOption(SocketOptionLevel.SOCKET,
SocketOption.BROADCAST, 1);
auto adr = getAddress("239.192.0.10", 54000);
udp_broadcast_soc.sendTo(, adr[0]);
Please Please Please Help, I am desperate!
This needs more context. What is your platform? Have you tried doing it
in C to see what works?
One thing that stands out so far is you are using IPV4 addresses and
constants everywhere, yet you are using IPV6_JOIN_GROUP socket option.
-Steve
Re: Phobos docs in pdf?
On 8/17/18 12:36 AM, SeanC4s wrote: I never program with a computer connected on-line. I need the standard library docs in some off-line format. The downloaded tarball comes with the full html documentation. Just open it from the file. That's what I've done (I generally am online to program, but sometimes, like when I'm on a plane, I want to have offline doc access). -Steve
Re: Possible bug in associative array implementation (and/or @safe checking)
On 8/16/18 4:45 PM, Aaron D. Trout wrote:
On Thursday, 16 August 2018 at 18:56:45 UTC, Steven Schveighoffer wrote:
On 8/16/18 2:32 PM, Aaron D. Trout wrote:
[...]
On Thursday, 16 August 2018 at 17:20:23 UTC, Steven Schveighoffer wrote:
Yes, this is the effect I would expect.
D has traditionally simply allowed slicing stack data without
question (even in @safe code), but that will change when dip1000 is
fully realized. It will be allowed, but only when assigning to scope
variables.
Thanks for the quick and knowledgeable reply! I think I understand
what's going on, but I'm surprised it is allowed in @safe code since
the compiler doesn't allow the following, even in non-@safe code:
int[] badSlice()
{
int[2] buffer;
return buffer[];
}
It's because it's on the same line. This is a crude "safe" feature
that is easily duped.
This is allowed to compile:
int[2] buffer;
auto buf = buffer[];
return buf;
But add -dip1000 to the dmd options and that fails.
I would warn you that I think dip1000 is too crude to start trying to
apply it to your project, and may have linker errors with Phobos.
I guess the compiler just isn't (yet!) able to catch that the
associative array is storing a slice of expired stack. I'm surprised
that the built-in AA implementation *allows* using slices as keys in
@safe code without copying the underlying data to the heap first.
This is clearly dangerous, but perhaps heap-copying slices
defensively would result in an unacceptable performance hit.
I wouldn't put too much stock in having safety in the AA. The AA is a
very very old piece of the compiler, that pre-dates safety checks, and
still is a bit of a kludge in terms of type and memory safety. If you
do find any obvious bugs, it's good to report them.
This issue came up while trying to eliminate unnecessary allocation
in my code. In my case, I could set a maximum key length at compile
time and switch my key type to a struct wrapping a static array buffer.
In hindsight, it was silly for me to think I could eliminate
separately allocating the keys when the key type was a variable
length array, since the AA must store the keys. That said, a suitable
admonition from the compiler here would have been very educational. I
look forward to seeing the full inclusion of DIP1000!
In this case, actually, the AA does NOT store the key data, but just
the reference to the keys. An array slice is a pointer and length, and
the data is stored elsewhere. The static version, however, does store
all the key data inside the AA.
That being said, you can potentially avoid more allocation with the
keys with various tricks, such as pre-allocating all the keys and then
using the reference.
In other words, eagerly stick the data into an array of arrays:
auto sets = setA.map!(j => setB.filter!(i => i % j ==
0).array).array;
and then not worry about duping them. But it all depends on your use
case.
Thanks again for the quick reply! I have a pretty firm grasp on what a
slice is (pointer + offset).
pointer + length, but maybe that's what you meant.
What I had meant by the comment "the AA must
store the keys" was that I had somehow gotten the (of course totally
mistaken!) idea that the AA only ever needed to *examine* the key rather
than actually storing it.
Right, the hash only gets you to a bucket, you still need the actual
value to compare for equality.
If that were the case, a slice of
about-to-be-expired stack would be perfectly fair game as a key. Am I
correct that doing this *would* be an OK way to avoid unnecessary
allocation if we knew the key already existed (as a heap allocated
slice) in the AA and we simply wanted to modify the associated value?
Yes, definitely! There have been a few new functions added to AAs
recently to help with only allocating *values* when not present, but not
a way to do the same with keys.
What you *can* do (but this involves 2 lookups) is:
int[2] buf = ...;
if (auto valptr = buf[] in aa)
{
// use *valptr to get the value
}
else
{
aa[buf.idup] = 0; // initial value
}
I don't think the storage of the key was considered when adding the new
functions (`require` and `update`).
Thanks also for the advice about -dip1000 and the state of the built-in
AA implementation. My code base has been changing to include more
AA-heavy data structures, so I think that in the near future I will need
to do some refactoring to make changing AA implementation easier.
I maybe said it more strongly than needed; AAs are generally safe, it's
just that I'm not surprised if there are holes. It's a type that the
compiler generally ignores a lot of rules for, and not everything is
covered. However, in this case, it was the slicing that was unsafe, the
AA had nothing to do with it.
Also, one last question: should this issue be reported as a new bug? My
understanding was that @safe code should not allow obtaining references
to expired stack
Re: Phobos docs in pdf?
On Friday, August 17, 2018 5:19:11 AM MDT SeanC4S via Digitalmars-d-learn wrote: > I used CUPS to print as pdf individual pages from the standard > library. I want to get all the basic information I need easily at > hand. > I used unpredictableSeed in my code. It seems to be a property > of something somewhere. > I hope it is thread safe. Who knows? I guess I'll look at the > source code like you say to try to understand. > The plan is to use D as a low level programming language as much > as possible. In particular to maintain the ability to translate > the code to other languages as easily as possible. > I wonder if there is an integer bit rotate instruction in D > somewhere? I see the dmd complier doesn't convert say s3=(s3 << > 45) | (s3 >>> 19); into a rotate instruction like gcc would. > Maybe I need to find some optimizer settings for dmd. If really want good optimization, then use ldc. dmd does a decent job, but ldc is much better. dmd compiles very quickly, so it's likely to be better for development, but if you want every ounce of performance, it's a poor choice. - Jonathan M Davis
Re: Phobos docs in pdf?
I used CUPS to print as pdf individual pages from the standard library. I want to get all the basic information I need easily at hand. I used unpredictableSeed in my code. It seems to be a property of something somewhere. I hope it is thread safe. Who knows? I guess I'll look at the source code like you say to try to understand. The plan is to use D as a low level programming language as much as possible. In particular to maintain the ability to translate the code to other languages as easily as possible. I wonder if there is an integer bit rotate instruction in D somewhere? I see the dmd complier doesn't convert say s3=(s3 << 45) | (s3 >>> 19); into a rotate instruction like gcc would. Maybe I need to find some optimizer settings for dmd.
Re: getopt defaultGetoptPrinter is not safe. Is there a reason for that?
On 17/08/2018 8:32 PM, Markus wrote: On Friday, 17 August 2018 at 08:09:52 UTC, Markus wrote: I wonder what's the reason for that? I wonder why it's not at least @trusted. Literally, can't I trust that method/function? It honestly looks like a simple case of nobody has yet bothered to do it. It should be a simple case as opening a PR and chucking @safe on the function(s).
Set optional function parameter
Hello,
In D there is a nice function:
auto Tuple!(int,"status",string,"output") executeShell (
scope const(char)[] command,
const(string[string]) env = cast(const(string[string]))null,
Config config = cast(Config)0,
ulong maxOutput = 18446744073709551615LU,
scope const(char)[] workDir = null,
string shellPath = nativeShell()
) @trusted;
It has got 5 optional parameters. For example I want set only the
fifth and all other leave with default values.
If it was C/C++ then I would write:
executeShell("my_command", nullptr, 0, 18446744073709551615,
nullptr, "my/path");
Long and boring...
What about D? Does it support something like this:
executeShell("my_command", shellPath = "my/path");
or
executeShell("my_command", default, default, default, default,
"my/path");
I mean - can I skip some arguments and set only one that I want?
Hm, Python, it seems to me, support this feature.
Re: getopt defaultGetoptPrinter is not safe. Is there a reason for that?
On Friday, 17 August 2018 at 08:09:52 UTC, Markus wrote: I wonder what's the reason for that? I wonder why it's not at least @trusted. Literally, can't I trust that method/function?
getopt defaultGetoptPrinter is not safe. Is there a reason for that?
Hi. I'm a big fan of @safe code. But within my first 20 program lines I already run into problems: Error: @safe function D main cannot call @system function std.getopt.defaultGetoptPrinter https://dlang.org/phobos/std_getopt.html#.defaultGetoptPrinter I wonder what's the reason for that? Cheers Markus
