31–40 of 53 posts
The syntax looks like this:
jsm.define("test", new Block(x64) {{
__asm(
"nop", // no-op
"ret" // return
);
}}).invoke();Earlier quoted context omitted.
It’s a fairly major point of contention, and we may not keep it. Note that it’s not a stable feature yet. As pointed out below, it’s this way because it’s basically a convenience into LLVM.
Keep it. Porting to rust is easier if it doesn't require a person to be an expert at two different kinds of inline assembly syntax. Being able to grab a chunk of inline assembly from a C project is very useful. Whatever you do, don't embed knowledge of the assembly language into the compiler. That way lies madness. Assembly is often used for new CPU features that are not yet supported by the compilers that people are…
The same path that Microsoft has decided to follow since they introduced 64 bit support. Compiler intrinsics.
Also copy paste inline Assembly from C into Rust only works for a specific C compiler.
Earlier quoted context omitted.
It’s a fairly major point of contention, and we may not keep it. Note that it’s not a stable feature yet. As pointed out below, it’s this way because it’s basically a convenience into LLVM.
Keep it. Porting to rust is easier if it doesn't require a person to be an expert at two different kinds of inline assembly syntax. Being able to grab a chunk of inline assembly from a C project is very useful. Whatever you do, don't embed knowledge of the assembly language into the compiler. That way lies madness. Assembly is often used for new CPU features that are not yet supported by the compilers that people are…
Sadly, this doesn't save you from that, in fact, it can be argued that the string syntax is what makes you need to learn a whole second set of syntax. This is due to clobbers.
> There is also the issue, I'm sorry, of the rust preprocessor. It will be written and it will be used.
I don't forsee this happening; Rust has powerful enough generic capabilities that even with tens of millions of lines of Rust existing today (I'd actually guess we're in the hundreds right now, but still), nobody has invented one yet. Getting away from the pre-processor is considered a pro, not a con.
Earlier quoted context omitted.
Keep it. Porting to rust is easier if it doesn't require a person to be an expert at two different kinds of inline assembly syntax. Being able to grab a chunk of inline assembly from a C project is very useful. Whatever you do, don't embed knowledge of the assembly language into the compiler. That way lies madness. Assembly is often used for new CPU features that are not yet supported by the compilers that people are…
> Porting to rust is easier if it doesn't require a person to be an expert at two different kinds of inline assembly syntax. Sadly, this doesn't save you from that, in fact, it can be argued that the string syntax is what makes you need to learn a whole second set of syntax. This is due to clobbers. > There is also the issue, I'm sorry, of the rust preprocessor. It will be written and it will be used. I don't forsee…
Yep, even ISO C++ is putting energy into making each standard revision one reason less to use it.
Earlier quoted context omitted.
The style used by Turbo C is strictly inferior. There is no way for the author of the assembly code to cooperate with the compiler's register allocator or instruction scheduler. You wouldn't even need both of those lines with gcc. You could ask the compiler to put 0x13 into ax, and the compiler might schedule that instruction far earlier or even take advantage of the value already being in the register by luck. Turbo…
Turbo C was a compiler done in 1990 for MS-DOS, naturally it was just an example. Your remarks are a mute point in modern Windows compilers with Assembly intrinsics, the evolution of those inline assembly instructions.
I've dealt with this, getting software to run in Visual Studio. The intrinsics are simply not available. You end up running code through gcc to produce assembly, then hacking up the assembly (way too much to write by hand) into a separate *.asm file for Visual Studio.
Vector stuff, if it isn't very new, is covered by intrinsics. Well, it is badly covered, with terrible failures to keep things in registers.
Once you get into exotic OS-level stuff, the intrinsics simply don't exist. The most important one is the ability to put an arbitrary byte sequence into the instruction stream. For example, suppose you wanted to add a Spectre fix to your JIT on day 1. You needed to fix a security problem, so waiting for a new release of Visual Studio isn't an acceptable option. You really truly need the ability to put weird byte sequences into the code. Visual Studio doesn't provide an intrinsic for that.
I don't see anything on that page referencing C++20. Am I missing something? On a related note, I always find the official docs for GCC inline assembly are insufficient for figuring out what I am trying to do. I nearly always have to resort to dumb trial and error. I was just recently planning to write some docs of my own on the subject. Not tutorial docs, but reference docs.
I believe it was discussed in Cologne, 'Enabling Constexpr Intrinsics......' - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p166... Quite a meaty document, should provide you with help for material on the subject.
I don't see anything on that page referencing C++20. Am I missing something? On a related note, I always find the official docs for GCC inline assembly are insufficient for figuring out what I am trying to do. I nearly always have to resort to dumb trial and error. I was just recently planning to write some docs of my own on the subject. Not tutorial docs, but reference docs.
I'm reminding myself of Z80 assembly at the moment, building a simple computer and I've done a bit of that.
Old, well-known feature of one of the most popular languages. I must be missing something, because I have no idea how this became a hacker "news" :)
Hacker News Guidelines What to Submit On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity.
Earlier quoted context omitted.
Turbo C was a compiler done in 1990 for MS-DOS, naturally it was just an example. Your remarks are a mute point in modern Windows compilers with Assembly intrinsics, the evolution of those inline assembly instructions.
It's not mute or even moot. Assembly intrinsics are not enough. I've dealt with this, getting software to run in Visual Studio. The intrinsics are simply not available. You end up running code through gcc to produce assembly, then hacking up the assembly (way too much to write by hand) into a separate *.asm file for Visual Studio. Vector stuff, if it isn't very new, is covered by intrinsics. Well, it is badly covered…
In a string literal?!?! We did better almost 40 years ago..., this is assembly in turbo pascal: procedure init; assembler; asm mov ax,13h int 10h end; You can even have only the asm block in a regular pascal function and make use of regular arguments in the asm block.