Inline assembly

[felixangell]

I wanted to port my Yash kernel thing to alloy, but I need inline assembly to make things a little easier... so inline assembly; how should we go about this?

[MovingtoMars]

Pipe it into GNU as?

I think the gcc syntax for output/input/clobbered registers in inline assembly is not great. A nicer syntax that makes more sense would be brilliant in Alloy.

[muscar]

Both GCC and clang support intel syntax, but it has some limitations.

[felixangell]

I'm not too sure about inline-assembly myself, it's rare that I use it. But if you guys have any ideas of what would be nice, throw em at me and I'll see what I can do. @MovingtoMars Are you implying we don't even use C's inline assembly stuff?

[MovingtoMars]

Sorry, I wasn't clear.

I just think that this syntax is ugly and has low readability:

asm ("cld\n\t"
             "rep\n\t"
             "stosl"
             : /* no output registers */ // ugly
             : "c" (count), "a" (fill_value), "D" (dest) // ugly
             : "%ecx", "%edi" // ugly
             );

This method-chaining solution seems nicer: asm("stuff goes here").setClobbered("%rax", "%rcx").addOutput(...).addInput(...)

I wasn't talking about the syntax of the assembly itself.

edit: github chomped up my newlines before, whoops

[felixangell]

@MovingtoMars Does look a lot cleaner, I like it.

[raoulvdberge]

IMHO I think that we should just provide a raw asm function, it is for libraries to add more syntactic sugar to this.

[felixangell]

@raoulvdberge Or both, perhaps?

[muscar]

@raoulvdberge :+1:

[raoulvdberge]

I still think we should keep it simple and just provide asm.

[felixangell]

@raoulvdberge We can do that to start with, and then we can add a nice wrapper around it later on.

[semrekkers]

Why not inline LLVM-IR code instead of inline assembly? Since you are porting the backend to LLVM, this may be better.

[felixangell]

@semrekkers Interesting idea, but I don't think it's the best choice, I'm not sure why and I'm not familiar with assembly. But I just have a gut feeling?

To elaborate, I think that in some cases people would prefer just having inline assembly over IR, since they would have to learn LLVM's IR too.

[raoulvdberge]

@felixangell I agree.

[SamTebbs33]

Also, I don't really think LLVL bitcode is made for humans to write :D A lot of people will need actual assembly for things like operating system development and drivers etc.

[semrekkers]

@felixangell @raoulvdberge @SamTebbs33 I agree but, keep in mind that IR is portable across different architectures and assembly not. And if people really want inline assembly, that is not a big problem in LLVM's IR. Or maybe we can implement both?

[raoulvdberge]

@semrekkers Also, the codebase is modular enough to allow for multiple code generators, and the LLVM code generator might not always be available, so that wouldn't be too portable.

[felixangell]

I feel inline LLVM IR is not a great idea, LLVM IR isn't stable since the compiler may compile with 3.x but not 3.y, and the IR could vary between those versions.

[semrekkers]

@SamTebbs33 I don't mean the bitcode but the IR xD

[semrekkers]

@raoulvdberge yeah but most popular architectures have support. @felixangell that's right, so I guess inline assembly +1

[felixangell]

@semrekkers I mean I think inline ASM would take priority for now, but I'm not saying we can't do inline LLVM IR, but for now it's not a great idea.

[semrekkers]

@felixangell I understand, it's fine! Maybe also implement volatile? Since optimizing asm is not always a good idea.

[raoulvdberge]

@semrekkers That is not what I mean, if the language is compiled without LLVM support, LLVM IR code cannot be ommitted.

[MovingtoMars]

What would be the point of inline IR? The reason inline assembly is included is for low-level operating system access for writing things like kernels (ie loading the GDT, interrupt handlers). I don't think IR can accomplish that.

[semrekkers]

@raoulvdberge Aah you mean when LLVM is not used as backend, I had not thought about that. At this point it is indeed not a great idea to implement inline IR, and I agree with @MovingtoMars. It was just an idea, because I do not know any language that supports "inline IR" you know? What I don't like about assembly is that it's using different syntaxes and opcodes on different architectures and IR is a kind of abstract assembly lang. That's why I came on the idea, but it's a bad idea after all :D

[raoulvdberge]

i still think we should just provide a raw asm function

[felixangell]

@ark-lang/owners conclusions please

I'm good with a raw asm function too.

[MovingtoMars]

@0xc6 Ark can link with external symbol archives fine right now. Granted, there is only a mechanism for linking to shared libraries right now, but you can still compile Ark files to object files and then link them with a static object file manually.

@raoulvdberge @felixangell Define "raw asm function". That doesn't really mean anything.

[felixangell]

@MovingtoMars No clue, just what raoul said lol. Was kind of thinking of how Rust does asm though when I wrote it.

[SamTebbs33]

Isn't that just something like

asm("mov edi, eax
add edx
sta edi")

[MovingtoMars]

@SamTebbs33 You can't just have that, you need syntax to tell the Ark compiler which registers are clobbered, etc. So you cannot use a true "raw" asm function.

[SamTebbs33]

@MovingtoMars Yeah but you get the idea of what I'm assuming they mean about a raw asm function.

[MovingtoMars]

@0xc6 It's not a high priority right now, but it would be nice to include later.

[kiljacken]

:+1: For osdev and the like, inline assembly is a big quality of life improvement (if done properly). Invoking an external assembler shouldn't be neccesarry, as the llvm backend support generating arbitrary assembly (http://llvm.org/docs/LangRef.html#inline-assembler-expressions)

[MovingtoMars]

@kiljacken this is exactly what I'm thinking. Plus, the compiler cannot inline external assembly functions, so you're essentially using a useless function call to do something like disable interrupts.

[kiljacken]

LLVM might be able to do such link-time-optimizations, but we currently do not have support in the compiler for specifying external libraries/objects to link with.

[kiljacken]

So let's get to some conclusions up in this one.

The simplest way to go about this would be to wrap the llvm syntax directly. This would mean doing asm(code, clobbers, values...) or for example asm("bswap $0", "=r,r", y). This could play together nicely with #692.

[felixangell]

@kiljacken looks good to me

[kiljacken]

As of ark-lang/go-llvm@b7878fa there are no hindrances with regards to implementing inline asm. Now we just need to agree on the syntax, and then implement.