/tech/ - Technology★

I rather hang myself then write x86 assembly. nice try intel.

>>1034610

I weep for what this board once was

>>1034604 (OP)

Thanks OP. I don't program too much assembly, but I am sure there are nuances to it like every other language.

>>1034604 (OP)

macro shits. Try a monad ya dingus.

>>1034622

How would you break these down into monads?

I mean, it's kinda cool if for some reason one really needs to write in assembly, but it still looks like dogshit compared to any normal language.

Seriously, that print function is not something anyone should ever write by hand.

>>1034624

>Seriously, that print function is not something anyone should ever write by hand.

Why?

>>1034626

I presume he's concerned about duplication of work, which is understandable. But if you're in a situation where you're needing to write Assembly for speed, having a custom print may be helpful.

>>1034626

>Why?

Try to explain what that function does exactly, in a way that allows a non-programmer to understand it.

>>1034604 (OP)

I've been wanting to learn assembly too.

Do you have any suggested resources/books for modern assembly OP?

Clearly I'm not going to start writing shit in pure assembly but I would like to learn how, to atleast be able to inline parts in C

Most of the shit I find online is out of date.

>>1034628

from the anchored thread

>>1034182

>>1034321

>>1034281

clearly some things in the C standard library are full of bloat, writing parts in assembly directly can result in dramatic performance improvements.

>>1034633

>Do you have any suggested resources/books for modern assembly OP?

I learnt a ton from a guy on /tech/ a while back, the rest was mostly looking at the output of compilers (the -S flag will spit out Assembly for you) and a lot of googling, scrolling through obscure forums etc.

Books and dedicated sites seem to be a dead end unfortunately.

>>1034628

In my opinion, duplication of work is a good method for learning how something is done.

>>1034631

>in a way that allows a non-programmer to understand it

It's pretty clear that the macro, which is different than a function, especially in assembly, sets 4 memory registers in the CPU that contain the system call to write, the location where to write, the message to write, and the length of that message. After preparing the computer for this system call, it then pushes a call onto memory, the stack, for a function that is ran after the system call to write is made. The system call is then made and at return it jumps to where the user function is called.

Personally, I don't know if I would've used macros for it or not.

>>1034634

The C Standard library isn't standard across implementations unfortunately.

>>1034623

store all registers -> call IO -> restore all registers

>>1034641

There's no need to restore any registers here.

>writing assembly by hand

That's not what you're supposed to do, autismo. You're only supposed to touch the assembly if your code has proven to be too slow even after every possible language and compiler optimization.

>>1034644

Please point to the post in which I said otherwise.

>>1034642

Yeah sure thing bucko.

>>1034647

What did you think

lea ebp, [esp-12]

>>1034644

>You're only supposed to touch the assembly if your code has proven to be too slow even after every possible language and compiler optimization.

Great. And how are you supposed to fix slow code with assembly if you've seen it.

>>1034652

By not LARPing and studying SICP/CLRS for at least one hour every time you fantasize about rewriting standard library functions like print in assembly.

1. There is LARPing

2. There is a cause for LARPing

3. There is a way to the cessation of LARPing

4. The ignoble 8ch path does not lead to the cessation of LARPing

the 4 noble truths of /tech/

>>1034654

>locking your brain into the thought process of some jews that sell a textbook

>>1034654

>>1034656

this is not how magic and revolutionary things happen

>>1034654

What are you blathering on about, not every program is going to have a magical solution where the hotspot can be solved with an optimised algorithm.

>>1034659

I'm saying that you should understand the fundamentals before fucking with shit you clearly have no idea when to fuck with or leave alone.

>>1034649

lmao

>>1034660

How are you supposed to understand anything if you don't write any code?

>>1034663

I've written fizzbuzz in over 70 languages, designed over 15 logos for various projects on /tech/, and have read SICP 3.2 times. Show some respect kiddo. Now optimize that print function for us, optimize it so well that it prints before you give it any input.

>>1034669

>muh AI overlord

>just like in my animuuu~~~

>>1034660

>you should never deviate from the standard library

>you should only use (((approved))) libraries

>you should only write code that confirms to what (((approved))) textbooks say

>no fun allowed

>>1034665

#include <unistd.h>
#include <sys/syscall.h>
#include <stdio.h>
#include <time.h>
char fizz[900]="1\n2\nFizz\n4\nBuzz\nFizz\n7\n8\nFizz\nBuzz\n11\nFizz\n13\n14\n"
	"FizzBuzz\n16\n17\nFizz\n19\nBuzz\nFizz\n22\n23\nFizz\nBuzz\n26\nFizz"
	"\n28\n29\nFizzBuzz\n31\n32\nFizz\n34\nBuzz\nFizz\n37\n38\nFizz\nBuzz\n"
	"41\nFizz\n43\n44\nFizzBuzz\n46\n47\nFizz\n49\nBuzz\nFizz\n52\n53\nFizz\n"
	"Buzz\n56\nFizz\n58\n59\nFizzBuzz\n61\n62\nFizz\n64\nBuzz\nFizz\n67\n68\n"
	"Fizz\nBuzz\n71\nFizz\n73\n74\nFizzBuzz\n76\n77\nFizz\n79\nBuzz\nFizz\n"
	"82\n83\nFizz\nBuzz\n86\nFizz\n88\n89\nFizzBuzz\n91\n92\nFizz\n94\nBuzz"
	"\nFizz\n97\n98\nFizz\nBuzz\n\0";

int main (void) {

	float startTime = (float)clock()/CLOCKS_PER_SEC;
	//syscall(SYS_write, 1, fizz, 900);
	register int    syscall_no  asm("rax") = 1;
	register int    arg1        asm("rdi") = 1;
	register char*  arg2        asm("rsi") = fizz;
	register int    arg3        asm("rdx") = 900;
	asm("syscall");
	float endTime = (float)clock()/CLOCKS_PER_SEC;
	printf("\nTime:%f\n",endTime-startTime);

    return 0;
}

Time:0.000028

#include <stdio.h>
#include <time.h>

int main (void) {
	float startTime = (float)clock()/CLOCKS_PER_SEC;
	puts( "1\n2\nFizz\n4\nBuzz\nFizz\n7\n8\nFizz\nBuzz\n11\nFizz\n13\n14\n"
	"FizzBuzz\n16\n17\nFizz\n19\nBuzz\nFizz\n22\n23\nFizz\nBuzz\n26\nFizz"
	"\n28\n29\nFizzBuzz\n31\n32\nFizz\n34\nBuzz\nFizz\n37\n38\nFizz\nBuzz\n"
	"41\nFizz\n43\n44\nFizzBuzz\n46\n47\nFizz\n49\nBuzz\nFizz\n52\n53\nFizz\n"
	"Buzz\n56\nFizz\n58\n59\nFizzBuzz\n61\n62\nFizz\n64\nBuzz\nFizz\n67\n68\n"
	"Fizz\nBuzz\n71\nFizz\n73\n74\nFizzBuzz\n76\n77\nFizz\n79\nBuzz\nFizz\n"
	"82\n83\nFizz\nBuzz\n86\nFizz\n88\n89\nFizzBuzz\n91\n92\nFizz\n94\nBuzz"
	"\nFizz\n97\n98\nFizz\nBuzz\n\0" );
	fflush(stdout);
	float endTime = (float)clock()/CLOCKS_PER_SEC;
	printf("\nTime:%f\n",endTime-startTime);
    return 0;
}

Time:0.000164

5.9x slower

>>1034669

Anon, what are you talking about. Nothing you're replying to has anything to do with the issue you're discussing. Could you calm your inner sperg and try to actually explain what you take issue with in words?

>>1034674

he's completely right though tbh

I moved some files around so the link in OP is broken, use this one instead

https://github.com/faissaloo/x86-asm-hello-world

>>1034672

AI won't be the overlord. The overlord will be the person or people who use AI to gain power.

This is the ultimate goal for the development of AI.

>>1034674

>explain what you take issue with in words?

>in words

>>1034701

'in words' is an expression used to imply that a person is speaking in a convoluted or confused manner and should rephrase in order to clarify. Is English your second language?

>>1034612

Was there honestly a time when it wasn't a dumpster fire?

>>1034707

Do you have a brain or do you need to write a program that will analyze what I said and break it down into smaller parts so it's easier for you to understand?

Just stfu and let your computer do the thinking for you.

>>1034673

This is cool. Are you using GNU implementation of stdio.h?

>>1034717

Yeah, 2014 /tech/ was awesome.

>>1034719

No I don't have a brain. Are you going to explain what you meant?

<using an account connected to your real life name

<using x86 instead of x86_64 assembly

<abstraction for exit syscall, but not for write syscall

<set macro sometimes changes flags and sometimes doesn't

<using function chaining for your print function so people can't use it in the middle of a subroutine

<having your print function clobber registers

>>1034726

>Are you using GNU implementation of stdio.h?

yes

>>1034738

Wow. I wonder what they do inside of puts() that slows it down that much.

>>1034665

What the fuck did you just fucking say about me, you little bitch? I'll have you know I graduated top of my class in every Microsoft certification, and I've been involved in numerous secret raids on Apple and Xerox HQ, with over 300 confirmed poachings of employees. I've written fizzbuzz in over 70 languages, designed over 15 logos for various projects on /tech/, and have read SICP 3.2 times. Show some respect kiddo. As we speak I am contacting my secret network of hackers across the USA and your IP is being traced right now so you better prepare for the storm, maggot. Now optimize that print function for us, optimize it so well that it prints before you give it any input. Or I'll compute some floating points with precision the likes of which you've seen.

FTFY

>>1034743

printf is just as slow, it seems to make multiple write syscalls, one on every newline, instead of just a single syscall for the whole thing.

>>1034730

><using x86 instead of x86_64 assembly

x86_64 is pretty ugly, I have more fun writing x86 and it's more useful anyway.

><abstraction for exit syscall, but not for write syscall

The exit syscall is abstracted just as much as the write syscall. In both cases their abstraction is tied to its actual utility in the program.

><set macro sometimes changes flags and sometimes doesn't

Yes, because again the abstraction is based on its utility in the program. There isn't a case here where this is an issue.

><having your print function clobber registers

Firstly it's a macro, not a function. Secondly there's no reason for me to preserve the registers here and it's faster for me not to do so. So why would I?

You have to understand that we're writing Assembly here, stop thinking like a C programmer.

>>1034728

so was /pol/

But it was never going to last. Regression to the mean is the worst law of our world.

>>1034747

I've never been a fan of /pol/, but they were alot more well behaved back then.

>>1034748

I think the userbase of /pol/ has totally changed but I'm pretty sure /tech/ is mostly the same.

At least I see the same posters for years.

>>1034745

Weird. Sounds like a fun project to optimize.

>>1034749

>I think the userbase of /pol/ has totally changed but I'm pretty sure /tech/ is mostly the same. At least I see the same posters for years.

Are you blind? There's a couple of the same old posters but nowadays we're full of /g/ refugees and /tv/-tier shitters.

>>1034746

>x86_64 is pretty ugly

x86 is ugly too. You wouldn't be writing it if you were just going off aesthetics. You probably write it because your CPU interprets it. Your CPU likely is x86_64, so shouldn't that be what you should use?

>Yes, because again the abstraction is based on its utility in the program

It's still messy. Additionally your exit macro should take an argument for the exit code. Your "print_clobber" is not an abstraction over write else you would call it write. Notice that print_clobber always prints to stdout. Also why don't you call exit, exit_clobber?

>There isn't a case here where this is an issue.

Not in this program, but when you go to reuse this code later, it might come back to haunt you.

>Firstly it's a macro, not a function

Did I say it wasn't a macro? Conceptually macros are functions.

>there's no reason for me to preserve the registers here

But if there was you would have to manually store them somewhere and then the subroutine you pass in for the "callback" needs to know where to restore them from.

>and it's faster for me not to do so

Well it's not faster if you need to preserve registers anyways. This is why it is better working at a higher level language as you can abstract over register allocation and saving / restoring registers.

>we're

No, you're

>stop thinking like a C programmer.

I'm not a Ctard.

>>1034758

>Well it's not faster if you need to preserve registers anyways. This is why it is better working at a higher level language as you can abstract over register allocation and saving / restoring registers.

this is why it seems like the ideal thing to do is use inline assembly where you feel like trying to optimize and

do I need to worry about any of this shit with the top code of

>>1034673

I assume not. i don't give a fuck what's going on with the registers after

asm("syscall");

i need to confirm but i'm pretty sure none of the shit you mentioned matters with inline assembly; it's still getting pumped through the compiler and the compiler is dealing with it.

https://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Explicit-Reg-Vars.html

"Local register variables in specific registers do not reserve the registers, except at the point where they are used as input or output operands in an asm statement and the asm statement itself is not deleted. The compiler's data flow analysis is capable of determining where the specified registers contain live values, and where they are available for other uses. Stores into local register variables may be deleted when they appear to be dead according to dataflow analysis. References to local register variables may be deleted or moved or simplified. "

>>1034758

>x86 is ugly too. You wouldn't be writing it if you were just going off aesthetics. You probably write it because your CPU interprets it. Your CPU likely is x86_64, so shouldn't that be what you should use?

x86 is ugly relative to other Assemblies, but it's nicer than x86_64 and still runs on my CPU so that's what I do for fun.

>Additionally your exit macro should take an argument for the exit code.

No, it shouldn't, because there's never a situation where I'm returning anything other than 0.

>Your "print_clobber" is not an abstraction over write else you would call it write. Notice that print_clobber always prints to stdout.

I'd say that writing to a special fd counts as an abstraction. This is mostly a semantic issue though.

>Not in this program, but when you go to reuse this code later, it might come back to haunt you.

I'm not writing a macro library, I'm refactoring code. You don't code preemptively when refactoring else you end up with bloat.

>Did I say it wasn't a macro? Conceptually macros are functions.

No they aren't, a function adheres to a calling convention.

>But if there was you would have to manually store them somewhere and then the subroutine you pass in for the "callback" needs to know where to restore them from.

No, I'd just tweak my macro to push ecx and edx (which are the registers the kernel clobbers), the kernel does the job of restoring those registers.

>Well it's not faster if you need to preserve registers anyways.

Sure, but I don't.

>This is why it is better working at a higher level language as you can abstract over register allocation and saving / restoring registers.

Why are you trying to compare Assembly to a high level language? They have different use cases.

>I'm not a Ctard.

Then what are you? A Rust dev? Go?

>>1034745

>>1034752

it only does that when stdout has a tty

>>1034763

Do you mean when stdout is a tty? Wouldn't that still be the case for a hardware terminal attached serially? It would still need to print to /dev/ttyS# instead of /dev/tty#.

>>1034612

Read a bible, intelaviv kike.

>>1034762

>No, it shouldn't, because there's never a situation where I'm returning anything other than 0.

First off, it doesn't matter since you are abstracting over the exit syscall which takes an argument and secondly the write syscall can fail so you might want to exit with an error in that case

>I'd say that writing to a special fd counts as an abstraction. This is mostly a semantic issue though.

There's different levels to the abstractions. You can have one that just wraps the sycall itself and one that is a special case of the other for printing out to stdout.

>I'm not writing a macro library

So what? It's good practice to not add special cases everywhere.

>a function adheres to a calling convention

As you said before, "stop thinking like a C programmer." There are no functions in x86 assembly.

>Sure, but I don't.

Not in this specific case, but if you were expanding this, making it more complicated, you might need to.

>They have different use cases

Assembly has zero use cases. Every use case it has is better suited to assembly + some other abstractions that make it easier to work with.

>Then what are you? A Rust dev? Go?

No, I did not develop the Rust programming language, nor am I a Go. I mainly program in Haskell and Idris.

>>1034770

>First off, it doesn't matter since you are abstracting over the exit syscall which takes an argument

Yes it does, because it's a refactor.

>and secondly the write syscall can fail so you might want to exit with an error in that case

I'm writing Hello World, not Sed.

>There's different levels to the abstractions. You can have one that just wraps the sycall itself and one that is a special case of the other for printing out to stdout.

Perhaps...

>So what? It's good practice to not add special cases everywhere.

The special cases aren't 'added', they are a natural consequence of it doing its job, it's good practice not to add bloat.

>As you said before, "stop thinking like a C programmer." There are no functions in x86 assembly.

Uh, yeah there are. What do you think CALL and RET are for?

>Not in this specific case, but if you were expanding this, making it more complicated, you might need to.

Yes, and I would add it as needed.

>Assembly has zero use cases. Every use case it has is better suited to assembly + some other abstractions that make it easier to work with.

This sentence is contradictory.

>I mainly program in Haskell and Idris.

I see...

>>1034770

>I mainly program in Haskell and Idris.

<proceed to shitpost about assembly

>Yes it does, because it's a refactor.

I don't know what you mean by that. The first half of that disagrees with me where the second half agrees.

>it's good practice not to add bloat

Then why are you adding bloat to your code to optimize takes less space and breaks dependencies clearing a register?

>Uh, yeah there are. What do you think CALL and RET are for?

Uh, no there aren't. CALL and RET are for procedures, not functions. Feel free to look at any documentation and it will back up the fact that they are for procedures.

>This sentence is contradictory.

Let me clarify. If I were to have a language that was x86 assembly + if statements, there really wouldn't be a good reason to just uses x86 assembly.

>>1034772

this but unironically and without Lisp. Interesting letter.

if life were an MMO and I had to make a choice of one static and one dynamic language to stick with, I guess I'd go with Ada and Lua. Without that kind of artificial constraint, it's easier to just learn a bunch of shitty dynamic languages and use whichever one has the most investment for a given task.

>>1034772

Oh, shit! Did you really get a letter from Uncle Ted?

>>1034669

this. these people are the reason why google and other bad things exists. they just do their job like robots without thinking what the thing they create will be used for.

>>1034796

>"thanks for your interesting letter now pls fuck off until you can into handwriting"

>you ask what qualities an individual should aspire too

<how about some self fucking discipline

<most young people who write me fail to write neatly, legibly and clearly

<you are no exception

lol

>>1034834

>>1034828

>>1034772

>>1034789

Ada was literally written by a kike and its used by the most kosher nation on the planet to kill bad goy mudslimes.

>>1034841

>>1034840

What's with all the ada shilling here lately? The government is literally the only place that uses it. And even they probably wouldn't shill it like you faggots do as if it's in any way better than Rust. LARPing as a glow nigger ada programmer is a really strange hobby tbh. It's kind of like those guys who stand outside the 7/11 in chinese ebay camo claiming they fought in the gulf war.

>>1034858

>LARPing

>as if it's in any way better than Rust

k.

>>1034787

>I don't know what you mean by that. The first half of that disagrees with me where the second half agrees.

>Then why are you adding bloat to your code to optimize takes less space and breaks dependencies clearing a register?

It's not bloat, since I'm not changing the actual code that gets output. I'm refactoring in order to make the code more readable.

>Uh, no there aren't. CALL and RET are for procedures, not functions. Feel free to look at any documentation and it will back up the fact that they are for procedures.

I meant to say procedures then.

>Let me clarify. If I were to have a language that was x86 assembly + if statements, there really wouldn't be a good reason to just uses x86 assembly.

Wrong, there are optimisations you can make in Assembly with regards to branching that you cannot do with a generic solution.

>>1034874

>there are optimisations you can make in Assembly with regards to branching that you cannot do with a generic solution.

You can still use regular assembly. When it's convenient to use the provided if statement then you use it, else use the old way. It's similar to comparing C with only goto and no control flow statements and C without goto.

>>1034858

Why do you care that the government uses Ada? Ada is cool even without government approval.

>>1034604 (OP)

>writing stuff in Assembly and ending up producing horrible code.

I'd be inclined to believe part of that is using an assembler to start with.

>I don't blame them, because pretty much the stuff about Assembly online is trash or unparsable.

I largely agree. It is in a sorry state.

Your program is no longer available to me.

If you'd care to see my thoughts on this topic, here is my thread: >>999945

If you have any questions, I can answer them here or there.

>>1034915

I moved some stuff around so it's here now

https://github.com/faissaloo/x86-asm-hello-world

>>1034638

>It's pretty clear that...

It's not, otherwise it would not take 4 lines to explain a simple print.

That's what is wrong with that code, 90% of the complexity is implementation details.

Also "macros are not functions" is semantic autism in this case.

>>1034673

>could my code be shit? no, it is the fault of the jews

Also you need to test for many various lenghts to see how well things scale.

>>1034911

What makes you think I care? I'm not the one who larps as a glow nigger ada programmer. And no, it's not. Without government funding and continued support in the form of outrageous government-priced license fees ada would not even exist.

>>1034919

>It's not, otherwise it would not take 4 lines to explain a simple print.

Oh, now you are arguing semantics? Get lost dude. Anon (you) asked for an explanation for someone who doesn't program. It's an entirely different explanation to someone who does program.

The only thing missing from this code are comments, like explaining "4" is the syscall for write, or that "1" is the system fp for stdout.

You might want to get some tums because you are green from jealousy.

>Also "macros are not functions" is semantic autism in this case.

And you are saying I am arguing semantics. Don't walk behind this guy because it stinks.

>>1034840

>Ada was literally written by a kike

Ada was (and is) designed by a committee.

>>1035025

GNAT is a free Ada compiler and it's free software. The compiler is free and so are the standards. So what's your point, nigger?

>>1035036

The entire point was, something as conceptually simple as print has to be so simple even without any tech background can understand it.

OP's print has side effects, which is anything but simple.

Stay salty tho.

If I ever want try do assembly should I just start with 6502?

>>1035048

>OP's print has side effects, which is anything but simple.

Side effects don't matter until you have a situation where they do. This is autism.

>>1035060

I would start with Z80 or ARM.

>>1035048

I am not the one salty. You are the one moving goal posts.

>>1034917

I tend to try to avoid macros, in part because they're a bit of a heavyweight item in my tool.

I'll use your set macro, as an example. If you really wanted to have a macro that set a register "in the most efficient way possible", you'd effectively have a tiny compiler rather than this simple macro.

That is, to truly set a register in the most efficient way requires understanding the state of the other registers, to see if you can modify their values with a shorter instruction, say, as an example. If you're programming at this level, you'd also gain by choosing numbers that the machine can manipulate more easily to start with, ARM being an example where this could be particularly important.

Those are my thoughts, anyway.

>>1035072

>Side effects don't matter until you have a situation where they do.

In more honest words, that means they lead to hard to reproduce and debug problems.

Putting side effects where they are not needed is pajeet tier and will fuck you over even in toy projects.

>>1035074

pic microcontroller assembly is pretty simple.

it's use is limited though, to pic microcontrollers

>>1035133

If the point is to write the code in the most efficient way as possible then it is needed.

tl;dr shithub user pooinloo tries to out-galaxy-brain a galaxy brain by fucking up a simple hello, world program in (32-bit!) x86 asm with a bunch of irrelevant scaffolding

>>1035113

>That is, to truly set a register in the most efficient way requires understanding the state of the other registers

I'm not sure if this is true. I think spending an extra byte or two in your icache is worth not adding a dependency on the value of another register meaning we have to wait on previous instructions to finish before we can set.

>>1035185

>I'm not sure if this is true. I think spending an extra byte or two in your icache is worth not adding a dependency on the value of another register meaning we have to wait on previous instructions to finish before we can set.

I care more about size efficiency than speed efficiency is an important detail.

Anyway, my point was writing maximally efficient machine code with macros can require increasingly complex macros to properly encode the knowledge a human programmer would have.

>>1035172

Making your code readable and maintainable is not 'irrelevant scaffolding'.

>>1035202

>make a program readable by making people jump between two files to read it

>make a hello world more maintainable

good job op

>>1035202

>>1035208

Sorry, I did that wrong

>making your code readable and maintainable

>by writing it in x86 assembly

Next throw portability in there by writing an assembly file that compiles for both arm and x86

>>1035233

>This is a good one. https://www.amazon.com/gp/product/9332573905

>Publisher: Pearson Education India; Third Edition edition (October 5, 2016)

>This book actually says: "This edition is manufactured in India and is authorized fro sale only in India, Bangladesh, Bhutan, Pakistan, Nepal, Sri Lanka and the Maldives. Circulation of this edition outside of these territories is UNAUTHORIZED."

>The text is riddled with known errors. Many of the same problems are just wrong. And there were a number of completely blank (missing text) pages.

pajeet detected

>>1035235

That's always the case with international edition books. If you're going to get a physical copy of anything you might as well spend a few extra shekels for the US edition.

>>1035208

1. It's a proof of concept dude.

2. Having a file with macro definitions separate from the main program means that you can have the definitions on one side and the program on the other. Having everything in one file means yo end up jumping around one big file which is a horrible experience.

>>1035273

learn vim or Emacs.

"I wonder how this function is defined"

vim: ctrl-W s (or v) , find it in the new window. ctrl-W c

M-. in Emacs and probably similar vim features mean that the definition being in another file is no barrier to you pulling it up just as easily, but the definition being the same file is no problem at all.

>>1035233

<not recommending Intel

<'s manuals

>>1035151

Shifting the inefficient parts outside that specific piece of code is cheating and into the code you're not benchmarking is cheating.

If your side-effects need to be cleaned up after the code has finished running, that cleanup needs to be considered to judge efficiency.

>>1035350

I'm not shifting the inefficiency out of that specific part of code, I'm shifting out of the entire program.

>>1035460

Bullshit, you're not restoring register contents so the rest of the program will have to do it for you.

>>1035487

Nothing that gets clobbered needs to persist, in many cases you will find that the registers clobbered by sysenter are immediately overwritten by code on a unifying path following a system call, or simply aren't used past that point (as is the case with this program).

>>1034604 (OP)

nigger there is no such thing as "cleanness" in assembly. you write your shit to fit tightly into clock cycles, save registers, maximize memory bandwidth, etc. even when performance doesn't matter real time concerns still may

assembly is dead. with something like modern x86 you're basically feeding commands into an SQL database and it "optimizes" it and executes it however the fuck it wants.

>>1034604 (OP)

>I've written Hello World properly, using modern interfaces & good code hygiene.

I think that you're just writing assembly with comments and macros that over-explain it, like it's intended to be read by someone who doesn't know any assembly. There isn't really anything necessary or important about the way you did things. You wouldn't need to explain yourself to an assembly programmer.

I can show you something I have written, this changes a RGBA bitmap into a BGRA one, this is because windows uses BGRA when rendering, so the change is necessary. I have it 128 byte-aligned and I use AVX because my CPU doesn't support higher extensions like AVX2/AVX512

.model flat

.const

RGBA_to_BGRA_shuffle_mask xmmword 0F0C0D0E0B08090A0704050603000102H

.code

;void bitmap_convert_RGBA_to_BGRA_128AVX(void *data,uint64_t size)
bitmap_convert_RGBA_to_BGRA_128AVX proc frame

	push rbp
	.pushreg rbp
	sub rsp,48
	.allocstack 48
	mov rbp,rsp
	.setframe rbp,0
	.endprolog

	vmovdqu [rbp],xmm6
	vmovdqu [rbp+16],xmm7
	vmovdqu [rbp+32],xmm8

	;rcx = bitmap, rdx = size

	shr rdx,7
	xor rax,rax

	vmovdqu xmm8, xmmword ptr RGBA_to_BGRA_shuffle_mask[rip]

loop1:

	shl rax,7

	vmovdqu xmm0,[rcx+rax]
	vmovdqu xmm1,[rcx+rax+16]
	vmovdqu xmm2,[rcx+rax+32]
	vmovdqu xmm3,[rcx+rax+48]
	vmovdqu xmm4,[rcx+rax+64]
	vmovdqu xmm5,[rcx+rax+80]
	vmovdqu xmm6,[rcx+rax+96]
	vmovdqu xmm7,[rcx+rax+112]

	vpshufb xmm0,xmm0,xmm8
	vpshufb xmm1,xmm1,xmm8
	vpshufb xmm2,xmm2,xmm8
	vpshufb xmm3,xmm3,xmm8
	vpshufb xmm4,xmm4,xmm8
	vpshufb xmm5,xmm5,xmm8
	vpshufb xmm6,xmm6,xmm8
	vpshufb xmm7,xmm7,xmm8

	vmovdqu [rcx+rax],xmm0
	vmovdqu [rcx+rax+16],xmm1
	vmovdqu [rcx+rax+32],xmm2
	vmovdqu [rcx+rax+48],xmm3
	vmovdqu [rcx+rax+64],xmm4
	vmovdqu [rcx+rax+80],xmm5
	vmovdqu [rcx+rax+96],xmm6
	vmovdqu [rcx+rax+112],xmm7

	shr rax,7

	inc rax
	cmp rax,rdx
	jne loop1

	vmovdqu xmm6,[rbp]
	vmovdqu xmm7,[rbp+16]
	vmovdqu xmm8,[rbp+32]
	add rsp,48
	pop rbp
	ret

bitmap_convert_RGBA_to_BGRA_128AVX endp

I'm using POASM to assemble this. The comment is just there to make things clearer because I don't have the calling convention totally memorized yet, but it's not actually necessary, I were more experienced I would have no reason to put that comment in, because it's just part of the calling convention.

>>1036084

that looks so simple. much nicer than most languages with their over 9000 }; symbols

>>1036084

>You wouldn't need to explain yourself to an assembly programmer.

This program is an example so obviously it's fairly simple to understand here. But at scale it's very easy for Assembly programs to become difficult to read which becomes a time suck.

And yes, I might need to explain myself to an Assembly programmer if they've never seen the clobber trick before or aren't used to Linux's ABI.

Secondly, when you shift left with the intention of multiplying (or right with the intention of dividing) you should use a macro so I don't have to guess why you're trying to shift. There could be any number of reasons why you're doing that.

Anyway let's dive into your code.

Firstly I don't understand why you would use your stack like this, instead of subtracting 48 and going up why not just use negative offsets with RSP across the rest of your code? You'd get rid of 4 instructions that way.

loop1:

This is a horrible name for a label, it doesn't tell me why I would be jumping here, or what the conditions for doing so are. This is on par with single letter variables. Of course I can tell if I spend some time reading your code but why should I be forced to do that?

>I were more experienced I would have no reason to put that comment in, because it's just part of the calling convention.

Rather than a comment you should have a macro, your code should be largely self explanatory. But even a comment is better than nothing because again it screws over the next guy who has to maintain it just that little bit more.

Instead of:

shr rdx, 7

I would prefer to see

divide_by_128 size_reg

>>1036133

It's very clear that this is just a loop. There is only one jump in the entire routine and it's clearly to loop over the next region of memory. What else would it be called? Distinct names are not necessary for something like a for loop.

The bit shifts are done because the memory is aligned by 128 bytes. So I can iterate through the memory at a 128byte granularity. This saves me doing things like adding 128 to rax each time, I can just shift it twice and increment. It should be simple enough, you should recognize it in this kind of situation. Just with all of the context surrounding it.

Subtracting from the stack, that is my mistake, I am doing it really, because the book I have been reading to learn about assembly, "Modern x86 Assembly Language Programming" does it this way to create a stack frame in x64.

>>1036178

It's literally no more complicated than a for loop. You can see in the comment rdx is the size. Then you can see that rax is set to zero. Then you can also see that rax and rdx are both shl'd by 7. It's a very obvious for loop, its the equivalent of that.

And you can tell from my pointer deferences that this loop is unrolled, on a 128 byte alignment, as well as the 7 bit shift, it's not so unclear. In C this is just:

size_t len = /* some length */;
len >>= 7;
for(size_t i = 0; i < len; i++){
    i <<= 7;

    /*do unrolled work*/

    i >>=7;
}

I really don't see how it's so unclear, what i'm doing.

>>1036178 We should rape all feminists!

>>1036084

>I have it 128 byte-aligned

I assume you mean 128-byte aligned (which is ghoulish overkill when no AMD64 feature to my knowledge requires anything greater than register sized alignment (64-byte for AVX512); and if you do indeed have it aligned, why on earth are you using the slower unaligned read instructions? Also why are you using the AVX v* functions when you make no use of their extended functionality? You could do this using using only MOVDQA (SSE2) and PSHUFB (SSSE3).

>>1036302

That's for the unroll. That's all. There are less comparisons being made in the loop. I am allocating using VirtualAlloc, so it's page-aligned anyway. Doesn't it save time if you do less comparisons,etc?

You're right, and I've rewritten this code with the suggestions... I don't actually know what the difference is between something like VMOVAPS and MOVAPS, what features does it give you? You can tell, I'm still not very experienced. And I realized, PSHUFB just does it in place, any way, so using VPSHFUB like that was pretty pointless... so I guess this only needed SSE3

>>1036306

The alignment is irrelevant for the unroll. You're thinking of truncating or extending the length. The alignment saves you from writing a prologue setup to your unrolled loop for any number of bytes smaller than the number of bytes processed per iteration and the length guarantee saves you writing an epilogue for the same reason.

VirtualAlloc is not actually page aligned, because historical reasons relating to weak order atomics on 64-bit DEC Alpha machines. It's actually 64k aligned (as opposed to 4k aligned which is the standard page size on AMD64).

The difference between VMOV* and MOV* in this context is just that the AVX version (referred to as VEX-encoded in the Intel documentation) can operate on YMM (256-bit) registers, by either doing an YMMWORD load or an XMMWORD load zeroing out the upper bits of the YMM register (and of course just doing an XMMWORD read to an XMM register and not touching the upper bits). If you're operating on 128-bit data you want to avoid those upper bits like the fucking plague because it creates a ton of dependencies in the ROB. It will tank performance like you wouldn't believe. There's an instruction to zero all the upper bits and nuke them from the dependency graph but I can't remember the name of it.

The difference between MOVAPS and MOVDQA is historical. It doesn't actually exist anymore since neither of these instructions reinterprets the data it loads. The original idea was to have entirely different instruction sets for working on integer and floating point data with SSE, but I guess no one cared because it really doesn't matter to the implementation.

Mostly though, the V* instructions that mirror prior SSE instructions just add a separate destination argument instead of using the first one implicitly. This can be good and bad, depending on how you look at it. Good because you might not want to overwrite some data and bad because it produces a longer instruction that takes more i-cache space if you don't need that. Generally you want to use the oldest instruction to avoid requiring features you don't actually need, letting it run on more machines as a result. There are of course counter-example, like how it (for a good while at least) was common parlance for compilers to produce ADD reg,1 instructions rather than INC reg even though the latter is shorter and more specific - because INC preserves flags where ADD overwrites them, which in a lot of the CPUs that were available at the time at least would cause the ROB to not get emptied as quickly, meaning it prevented parallel instruction issuing and thus was slower in the long run.

>>1036307

I see, this is very interesting... I don't have a very useful reply, I just want to say that, I do appreciate that you took the time to explain these things to me. It all makes sense.

>>1036084

>You wouldn't need to explain yourself to an assembly programmer.

>I were more experienced I would have no reason to put that comment in

Comments and clarity are fundamental to save time and make teamwork easier, stop showing off and learn how to make efficient use of your skills.

>>1036356

Some time ago we had a thread here where people talked about when are comments necessary. The "code pro" consensus was, unironically, "only a link to the paper you are implementing at the top of a function, and possible deviations of said paper when they happen inside the function". Also all variables should be single letters because a good programmer should be able to understand and it is The C Way, and comments are bad because they might be outdated if the code changes and the comment is not fixed.

The Multicsfag was right, and /tech/ is full of larpers

;; reply begin

>>1036363 ;; refer to post id 1036363, which we are replying to (with link)

>all language's comments should look like typical assembler comments ;; mock stupid thing that referred post said

;; reply end

>>1036356

>>1036363

Teamwork is really an off topic and entirely separate concern, this isn't code for anyone else but me to read later. It's clear what's happening and you should only really put in comments when there is a special reason to do so, I know lots of people like to over-comment their code, but it's really not necessary most of the time. It's not "showing off", there isn't anything purposeless about what I'm writing.

>>1036307

>because INC preserves flags where ADD overwrites them

No, both INC and DEC will overwrite flags, that's why you can do cool stuff like

dec rcx
jnz .loopStart

As a side note, I've used RCX here because it is traditionally the counting register (i.e Register Counter eXtended).

>>1036423

Most instructions set some flags. INC and DEC specifically preserve some. See the manual. Depending on what can be done to shadow the flags, this can be a big disadvantage to speculation.

>INC

>Adds 1 to the destination operand, while preserving the state of the CF flag. The destination operand can be a register or a memory location. This instruction allows a loop counter to be updated without disturbing the CF flag. (Use a ADD instruction with an immediate operand of 1 to perform an increment operation that does updates the CF flag.)

>ADD

>The ADD instruction performs integer addition. It evaluates the result for both signed and unsigned integer oper-ands and sets the CF and OF flags to indicate a carry (overflow) in the signed or unsigned result, respectively. The SF flag indicates the sign of the signed result.

https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-2a-2b-2c-and-2d-instruction-set-reference-a-z

>>1036416

>I don't consider needing to read multiple lines of code 'obvious'.

Do you want to know what code does without reading it? I only posted the C equivalent because you're acting like you don't understand what a bit shift does. This isn't me having to go to lengths to explain what's happening, this is you being retarded about obvious code.

>>1036445

I really don't know what to say to you. This is really simple, obvious code, and you insisting that it's unclear, unreadable, just tells me that you aren't comfortable with programming. There's really nowhere further to go, this is obvious, and you should just get it. You can tell that this is a loop counter, so you know that it's not iterating over a bit field. Especially since there are only three operations in between, which use it as an offset. It's clear code, you just don't know what you're talking about. Do you want me to leave a comment in between every line walking you through it? Or wait, you think that

>Comments obscure code and should only really be used for documentation, your code should be self-explanatory.

which it IS. you not understanding what's happening, is your problem.

>>1036452

Stop excusing your bad code. Self-explanatory code reduces the amount of context needed to understand it to the minimum, your code is nowhere near that.

>>1036479

You've already explained to me that your idea of "good code" is renaming shr 7 to "divide_by_128" like its not already obvious. So I don't see any point in taking anything you have to say about this seriously.

Leaving comments is 101 of programming. If somebody doesn't leave comments, she would be a slef-taught programmer.

>>1036649 She must be a self-taught programmer, so nobody taught her why programmers have to leave comments.

>>1034673

Run both versions at least 15 times, and then do a proper t-test. A single sample tells you basically nothing.

>>1036694

This is the case of a log-normal distribution with standard deviation known. As such we can perform our analysis on only two samples. Without even doing the math it's obvious that a factor of six difference couldn't occur by random chance, p<.001

>>1036739

I'm not even doubting that write is faster, but the sample doesn't show this. You are measuring things at the noise level.

>>1036748

what he's measuring is a bunch of syscalls vs. one syscall. There's a whole 'nother thread where this was all sussed out. https://8ch.net/tech/res/1034182.html

>>1036748

I'm saying that a factor of six is well above the noise floor. This comes from an analysis of the runtime distribution of similar programs. If you doubt me you can create trivial deterministic programs and test their runtimes a couple times, you will find that it never varies by a factor of six.

In general we can only apply mean value theorem on large samples, but if we know our distribution is normal, and we know the standard deviation, then we can apply it even to small samples like this.

>>1036762

The mean value theorem has nothing to do with statistics.

>>1036762

> If you doubt me you can create trivial deterministic programs and test their runtimes a couple times, you will find that it never varies by a factor of six.

The reason you have to do a proper statistical analysis is because the program you're testing is not the only thing running on your machine. It's particularly important for things with ridiculously fast runtimes, like in this instance. Try it for yourself sometime, the variance will shock you.

>>1034679

>>1034669

No he's not. He's regurgitating what comes from sensationalist sentiment that is rather typical for journalists who don't really know what they are talking about. When you actually work in tech you learn to not overestimate all the hypes. Well, not everyone learns that, which is quite an annoyance.

A wise man once said, the most important thing in programming is naming. And indeed, we programmers are really good at giving things pompous names that make them seem like otherworldly inventions. But when you do that all the time you should be able to stop following the hypes. What's being worked on is called weak artificial intelligence. What people think of when they hear about artificial intelligence is called strong artificial intelligence. And that thought seems to be so engraved into many people's minds that they can't even turn it off when they are talking about what really is a glorified, 'stateful' if you will, data collection algorithm.

>>1036768

Correct.

>>1036834

>because the program you're testing is not the only thing running on your machine

Another common problem is that benchmarks only look at a single part of a program. This means that the processor doesn't have to keep the rest of it in it's cache or whatever leading to a decreased performance than the benchmark when actually used.

>>1036834

>It's particularly important for things with ridiculously fast runtimes,

Wrong. Ridiculously fast runtimes fit into a single scheduler timeslice. The longer the runtime, the more likely it got pre-empted. At even faster speeds (ns level) clock accuracy becomes a problem, but the sub millisecond level is the sweet spot for timing accuracy.

>Try it for yourself sometime

no u

>>1036952

Whatever you say, smart guy. In spite of your theorizing, actual experience proves otherwise.

>>1034841

>the language is good though, so his plot failed. Now you can use the enemy's own tools against them.

Well said, and the same applies to Lisp.

If a tool is good, it's good, even if it was made by an enemy. Take advantage if it and beat him at his own game.

>>1034744

Please finish.

Using macros is an interesting Idea, and maybe saves some function call overhead. I think this will not scale well, but cause the complexity of your building blocks scales, there will start to be side effects in your macros, and the user will have to memorize side effects that are implementation specific to use them

>; Sets a register to zero, note that this will affect CFLAGS

I think that as complexity scales, function calls will be better - which is why procedural programming happened. I do think your use of macros is interesting, and a few look pretty useful but this 'galaxybraining' of helloworld destroys the point of helloworld as an education tool - you want new learners to understand what a syscall is , and the function call abi. Abstracting those details in macros probably makes it harder to learn whats happening to a new user.

>>1037522

>if you didn't work at AT&T in the 80s, you are my ENEMY

Rob Pike? I didn't know you posted here.

>>1034634

is unistd any better

DAILY REMINDER THAT THE MODS ARE COMPROMISED MOSSAD/CIA SHILLS

Oof, the racism in this thread!

I smell some satanic fuckery here.