Thread 106215192

Why not just write assembly at this point? You'd probably get better portability writing your own transpiler too.

how can you get so obsessed about so little?

it's kinda amazing compiler is able to optimize out that absolute abomination of source code.

How ?

>>106215292
Right? This thread makes me want to use systems programming languages with advanced compilers more than it makes me want to use assembly

>>106215192 (OP)
>>106215299
tail call optimization, it wouldn't work with O0

>>106215192 (OP)
Guess

I guess we finally have a sufficiently smart compiler.

>>106215378
This isn't just tail call optimization though?

Wtf it's real

>>106215461
it is though

>>106215192 (OP)
I don't know, feels hacky, i.e. ( i -1) to false, then everything is false, unlike the normal %2 expression.
bool iseven(unsigned int i) {
if( i % 2 == 0) return true;
return !iseven(false);
}


Maybe i'm just a creature of habit..

are you ever going to do anything? is this your only hobby?

>>106216284
Surely you must be trolling, right?

>>106215796
He is right. There is more than one optimization at play. Tail call optimization would turn this into a loop without using a call instruction. Further optimizations made this no longer a loop. There was an anon yesterday who showed the exact method used by the compiler to eliminate loop invariants. I don't think we need to keep posting the same shit over and over again though.

>>106215359
So you can masturbate to recursion while the compiler just writes the obvious code for you?

>>106215378
Pretty sure the negation ruins tail call since you need to evaluate the function return to negate it.

>>106216284
isEven(2) -> !isEven(1) -> !!isEven(0) -> !! true -> ! false -> true

>>106216402
isEven(n) -> ! isEven(n-1) ->...-> !^n isEven(0) -> !^n true

>>106215192 (OP)
>>106216284
LMAO @ that code
this board is clown world

>>106215192 (OP)
>Why not just write assembly at this point?
i want to write less

>>106216484
Makes sense but brevity comes with understanding

>>106216484
Now don't call the function

>>106216501
No code is generated. Why would you compile something that will never be used?

>>106216484
.globl iseven
iseven:
test dil,1
sete al
ret

>>106216524
That's exactly equivalent to calling a pure function and not using the return value

should pass the faux "depth" thing as a parameter so your function is in tail position.

fn is_even_real(num: u32, state: bool) -> bool {
if num == 0 {
state
} else {
is_even_real(num - 1, !state)
}
}

fn is_even(num: u32) -> bool {
is_even_real(num - 1, true)
}

>>106216541
weirdo

>>106216767
bizarre ASM output.

>>106216484
>using a 32-bit not and and when only the last bit is required
what a shit compiler

>>106216718
>>106216718
> is_even_real(num - 1, true)
hmm, oops.
should just be num.

>>106216540
>>106216785
>>106216767
--opt:none

>>106216824
that's 12 more characters than my asm solution

>>106216789
There is no benefit in using 16 or 8 bit operation

>>106216921
i am pretty sure you could find several CPUs where it matters

auto isEven = [](int i){ return (i % 2) == 0; }


Here's your optimal C++ code.

>>106216941
That's not the case here, though
You can target said CPUs and the output is going to differ

e(){(($1%2))&&echo Odd||echo Even;}; e 10

>>106216986
actually, it would matter in every CPU, because "and al,1" is encoded as two bytes, but "and eax, 1" is encoded as 3 bytes

>>106216921
.exe would be smaller.

bool is_even(unsigned int i) { return !(i & 1); }

Brainlets ITT shitting out their fizzbuzz solutions while missing the point of why the OP picrel is interesting

>>106217022
>>106217049
And slower with x86-64

>>106217118
I've heard all the bitwise operations require 1 cycle.

>>106217087
Ya, how the fuck does LLVM do it? I know it can detect summation series done with loops too.

What we need is an AI system that can look at billions of lines of high level code across projects and pull out patterns that humans could easily see, but can't because of the scale involved. Then add those to language. Not replace langauges with talking to a chatbot.

>>106216720
Are you actually serious?

Clever girl.

>>106215192 (OP)
There a no decent Assembly IDEs

Assembly code should look something like this.
add:
mov eax, [edi]
xor eax, 0
jz recursion
mov eax 0
ret

recursion:
mov eax, [edi]
add eax. 1
mov [edi], eax
mov eax, [edi+4]
sub eax. 1
mov eax, [edi+4]
jmp add


I guess the intermediate representation is where they do all the optimizations.

I spend time more on Godbolt than actually programming.

>>106218266
Yeah.

>>106215192 (OP)
because you'd have to write a ton of stuff from scratch, not only for different architectures but for different versions of the same architecture with different sets of instructions (or just not support all instruction sets, or code to the lowest common denominator, missing out on specialized instructions), and any OS interaction (e.g. syscalls) would be different for different OSes
a transpiler would be full of nitpicky details and bugs and would probably end up reimplementing a ton of stuff that's already been implemented in various compiler backends, but not as well as it has already been done

>>106215378
That's not a tail call though, but thanks for playing.

>>106215192 (OP)
why write anything?
just ask AI to write the program for you.

prompting is the future

>>106218949
wtf is fucking wrong with you fucking aberration?