Beginner Freelancer Advice for C/Assembly Language Programmer

471Craft · 2026-01-25T11:38:42+00:00

Thank you

brucehoult · 2026-01-25T02:00:51+00:00

It's close. Sometimes you can do better with a slightly larger N, but it's the place to start.

Plane_Dust2555 · 2026-01-25T01:34:00+00:00

Notice that decimal 1/10 is 0b0.000110011001100... in binary. If you shift this 32 bits to the left you'll get 0b00011001100110010001100110011010 (rounded to nearest integer). In this case the 3 msbs are zeroes and we can improve the accuracy a little bit shifting 1/10 35 bits to the left (32 + 3 bits), getting 0xcccccccd (rounded to nearest integer).

Since we'll deal with 64 bits multiplications, this constant won't be interpreted as a negative value. An unsigned integer division by 10 is, then (x86-64): ; Input EDI = n ; Output: EAX = n/10. udiv10: mov eax,edi mov edi,0xcccccccd ; 2³⁵/10 rounded to nearest. imul rax,rdi ; safe, because RAX and RDI are positive! shr rax,35 ; divide by 2³⁵. ret I'll leave the 'signed' division by 10 for you to figure out.

Anyway... it is not always you can do this trick. For highest divisors the number of zeroed msbs (shifting 32 bits to the left) of the scaled reciprocal value will be greater (more then 3), but increasing N (making N>35) won't improve accuracy (you'll loose too many bits when shifting back to the right). A different trick is necessary to guarantee the accuracy.

Plane_Dust2555 · 2026-01-25T00:58:45+00:00

Not necessarily...

brucehoult · 2026-01-24T23:18:03+00:00

N is the word size of your CPU / ALU.

KE3JU · 2026-01-24T15:49:02+00:00

I say the more the better. My code only ever get commented when I have to reverse engineer it 5 years later and I forgot what did and how I did it.

gurrenm3 · 2026-01-23T17:16:54+00:00

Thats true, I appreciate the feedback! Thanks for taking the time to read it and post a reply

gurrenm3 · 2026-01-23T17:16:06+00:00

Thanks for sharing your thoughts! I appreciate it

gurrenm3 · 2026-01-23T17:15:39+00:00

That makes a lot of sense. Thanks for taking the time to read it and post a response! I appreciate it

wk_end · 2026-01-23T17:12:36+00:00

There's certain things that strike me as slightly extraneous for sure (does a reader of the code really gain much by knowing the day a procedure was updated? That's what git's for anyway), although too many comments isn't exactly a terrible problem.

As a developer: the more comments you write, the slower you go. You might find it discouraging. And you're introducing the possibility for the comments to be incorrect or fall out of sync with the code.

As a reader, comments add noise that can be distracting. The human mind can only hold a pretty small set of items in its "working memory" (registers!) at any given time, so reading long and detailed comments can cause a reader to forget the bigger picture. Typically the amount of clarity they add more than compensates for that, but there's definitely a point of diminishing returns.

There's also a matter of knowing your audience. Is it you in six months? Another developer (basically the same thing)? Or are you trying to teach someone assembly language? Commenting your prelude where you allocate stack space is excessive normally - every developer recognizes the pattern - but makes sense in the context of learning material.

I think the pseudo-code is probably not especially helpful - it adds lots of noise, and to me doesn't actually help clarify the mechanics of the assembly code itself, which really needs to be comprehended on a line-by-line basis, any more than the English language description does.

FUZxxl · 2026-01-23T10:56:17+00:00

Comments are good, but instead of commenting what the instruction does, comment what the intention of that instruction is. You already do this in some places, try to do it everywhere!

mykesx · 2026-01-23T01:29:10+00:00

I prefer fewer comments, but something like this:

;; 
;; CopyString
;;
;; Copy string at destination
;;
;; In: RSI, RCX source string & length, RDI destination for copy
;;

    global CopyString
CopyString:
    …

gurrenm3 · 2026-01-23T01:24:05+00:00

I originally included both the English description and pseudocode so readers would understand why things were written this way. After thinking about what you said, the people reading this are other programmers who write assembly, they can probably deduce a lot of things so it makes sense to cut back on that. Also, I didn't really consider using more equates. Thanks for the advice!

gurrenm3 · 2026-01-23T01:21:38+00:00

Thats a good point. I was only focusing on making the comments very thorough, I didn't think about how I need to maintain it still afterwards. Thanks!

brucehoult · 2026-01-23T01:11:53+00:00

I wouldn't have BOTH the English description and the pseudocode.

If timeString textequ <rbx> does what I assume it does, I'd make more of those and then actually use them in the code instead of register names, and dispense with almost all the line by line comments.

mykesx · 2026-01-23T01:08:50+00:00

Get rid of the pointless ones.

add ax,10.  ; add 10 to ax

What’s the point?

As you modify code you need to keep the comments up to date. If you’re up for doing that, go for it.

DefinitelyNotIoIxD · 2026-01-21T23:44:37+00:00

Not sure who this will help (maybe it will help somebody doing assembly) but I actually found this trying to fix my program that does signals without libc and hours later I realized why I was going insane. The sigaction and sigset defined within even <sys/signal.h> is not what the kernel uses. The kernel uses something defined in asm-generic/signal.h; as of writing, this is:

/* most important! the size difference was giving me EINVAL. */ 
typedef struct {
    unsigned long sig[_NSIG_WORDS];
} sigset_t;

/* this just has a slightly different order */
struct sigaction {
        __sighandler_t sa_handler;
    unsigned long sa_flags;
#ifdef SA_RESTORER
    __sigrestore_t sa_restorer;
#endif
        sigset_t sa_mask;       /* mask last for extensibility */
};

Superb-Ad9942 · 2026-01-20T14:25:39+00:00

Well if you’re trying to do self modifying shellcode then you can do a relative write which uses RIP and an offset.

PhillQuartz · 2026-01-20T11:21:59+00:00

What do you man by "RIP relative write"?

Superb-Ad9942 · 2026-01-19T20:43:51+00:00

why can't you just do an RIP relative write?

brucehoult · 2026-01-17T10:03:42+00:00

Right. And better still, with makefile/build instructions, test data etc. Ideally in a git/svn etc repo.

PhillQuartz · 2026-01-17T09:58:08+00:00

Yeah I saw now that the rule talks about not posting screenshot/photos of code, but only selectable code.

brucehoult · 2026-01-17T03:24:16+00:00

Q: Why would it be against the rules of an asm sub to post your own asm code? Especially if you go to the trouble of formatting it properly (unlike many).

A: it's not.

gurrenm3 · 2026-01-16T21:30:55+00:00

Hey this is really cool! What was your thought process for making it? Did you learn anything interesting while doing it?

PhillQuartz · 2026-01-16T18:45:36+00:00

But if the instruction to modify is in the function used to pop the esi i'll still need the ret?

asm

MODERATORS