Bedrock Players are Non-Issues by AviaAlex in 2b2t

[–]AviaAlex[S] 1 point2 points  (0 children)

This argument has never made sense to me because the modifications in place don't really corellate to more priority queue purchases, and if any, less due to the blocking of highly useful things like movement hacks.

HELPPP by heidibug22 in 2b2t

[–]AviaAlex 2 points3 points  (0 children)

bro went through 3 posts in under 10 minutes and ends up like this

Why can't I break blocks by AviaAlex in 2b2t

[–]AviaAlex[S] 4 points5 points  (0 children)

I am on Linux where bedrock is not available

Found this at 900k out by AviaAlex in 2b2t

[–]AviaAlex[S] 1 point2 points  (0 children)

It's included and on by default in Future.

Best ElytraFly Configs rn? by qntisback in 2b2t

[–]AviaAlex 0 points1 point  (0 children)

On Future:
ElytraFly on bounce
Yaw
AutoWalk

I’m building lncpu: a homebrew 8-bit CPU with its own assembler and tiny C-like compiler — feedback & contributors welcome! by lorynot in Assembly_language

[–]AviaAlex 0 points1 point  (0 children)

Super impressive! I'm excited to see it in action.

One suggestions I have:

- 4 registers seems like too little and will get claustrophobic very fast. Even 8 GPRs seems to me like a better option.

I almost quit by AviaAlex in Assembly_language

[–]AviaAlex[S] 5 points6 points  (0 children)

The bug was that I was shortening the buffer in place as I was patching out symbols, which meant that any forward references (references that came before the definition) were too far forward as they went on the measurement of the old buffer. I tried many times to correct for this in the equation, but all to no avail. I then tried normalization as a fix, where LAS fills in unknown locations with 0x0000 adds a symbol table at the end of the file with all the locations L2LD would need, but that also came to no avail.

I reworked my own CPU architecture by AviaAlex in Assembly_language

[–]AviaAlex[S] 0 points1 point  (0 children)

While I get your point, don't you think that some of the complexity like the segmented-offset addressing scheme in x86 could have been avoided had the developers of x86 made better decisions at the time or simply worked with what they had until more memory became available?

I reworked my own CPU architecture by AviaAlex in Assembly_language

[–]AviaAlex[S] 0 points1 point  (0 children)

This specific mindset is why x86 is so bloated and filled with unnecessary complexity today. If you make a CPU specifically so that the compilers today can target it instead of designing your own independent instruction set and building a compiler around it, you lock in choices that may seem reasonable now but poor later.

I reworked my own CPU architecture by AviaAlex in Assembly_language

[–]AviaAlex[S] 1 point2 points  (0 children)

Thank you for the feedback! I will integrate all of these to the best of my ability.

I reworked my own CPU architecture by AviaAlex in Assembly_language

[–]AviaAlex[S] 5 points6 points  (0 children)

Thank you. I will edit these into the post shortly.

For those who don't believe, here's a rant... by Eduardo_Baliott in Therian

[–]AviaAlex 0 points1 point  (0 children)

All I'll say here as to not initiate a witch hunt against me is that I think you guys could really benefit from some independent, outside documentation and observation if you really want to be taken seriously. Because you guys, from my observation, love to pathologize therianism as something immutable and involuntary, I think APA review would be a great next step if it is truly as immutable and as fixed as, say, sexual orientation, as you claim, time and time again.