A forum engine written in Assembly(asm32.info)
asm32.info
A forum engine written in Assembly
https://asm32.info/fossil/asmbb/index
135 comments
The flat assembler (which assembles this project) is worth checking out if you haven't already: https://flatassembler.net. I first played around with it almost 20 years ago and it was noticeably more ergonomic and productive than masm, nasm, to say nothing of gas. I imagine it was designed for human programmers rather than primarily compiler front ends, so it's a popular choice for hand-written assembly projects.
Unfortunately FASM is written in 32bit assembly, which means it won't run on recent macOS versions.
Not an issue for NASM, since it's written in C.
Not an issue for NASM, since it's written in C.
I'm not seeing a lot of difference between flat assembler code and NASM code.
What in specific makes flat assembler better than NASM?
What in specific makes flat assembler better than NASM?
I wouldn't personally say it's better, so I can't speak for OP; but generally people that use FASM prefer it for two reasons: 1) it's self-compilable (vs NASM, which is C) and 2) they like its macro system.
This is amazingly fast to my eyes.
I am endlessly annoyed by slow interfaces. At $DAYJOB I have to use a web and desktop GUI for managing CheckPoint firewalls. These often will freeze for dozens of seconds, and generally make my computer crawl. I feel that this should not be acceptable in 2023.
I am endlessly annoyed by slow interfaces. At $DAYJOB I have to use a web and desktop GUI for managing CheckPoint firewalls. These often will freeze for dozens of seconds, and generally make my computer crawl. I feel that this should not be acceptable in 2023.
This is one of the reasons I really like the Mikrotik network gear, because of the Winbox application for management. It's Windows Forms (GDI) in the MDI style of most Windows apps of circa 2000. Lightning fast, responsive, and with nice touches like being able to drag files on/off the interface to upload/download and the ability to copy/paste entries like they were lines in a text file.
I know why the web for UI took over, but I sure do miss Windows forms-based applications. The web is fine for the UI to a bank or some other tool you don't interact with that often, but for tools where you can spend hours working inside, browser-based interfaces are terrible.
I know why the web for UI took over, but I sure do miss Windows forms-based applications. The web is fine for the UI to a bank or some other tool you don't interact with that often, but for tools where you can spend hours working inside, browser-based interfaces are terrible.
Also unusable by many people - I see mostly macbooks around me, with some Linux laptops or Chromebooks. Windows is for those super-low-privileged users who cannot be trusted with their own system and need IT to manage them; or for gamers.
And yes, I can probably run the management software in wine, but I will avoid it if I can.
And yes, I can probably run the management software in wine, but I will avoid it if I can.
They recommend and 'support' running it in Wine. I haven't tried, but I'm sure it works fine given Wine tends to work best with no frills Win apps from a decade ago.
> I am endlessly annoyed by slow interfaces. At $DAYJOB I have to use a web and desktop GUI for managing CheckPoint firewalls. These often will freeze for dozens of seconds, and generally make my computer crawl. I feel that this should not be acceptable in 2023.
This is probably not a problem of the principal slowness of the software. With a high likelihood (source: personal programming experience of my colleagues and me), the root cause when the GUI freezes in such situation is typically rather that some operation that needs a little bit of time (say, a server request) is done in the GUI thread, thus blocking the processing of any other event (message). Windows programming is very sensitive in this regard.
This is probably not a problem of the principal slowness of the software. With a high likelihood (source: personal programming experience of my colleagues and me), the root cause when the GUI freezes in such situation is typically rather that some operation that needs a little bit of time (say, a server request) is done in the GUI thread, thus blocking the processing of any other event (message). Windows programming is very sensitive in this regard.
> and generally make my computer crawl.
Sounds like its worse than that.
Sounds like its worse than that.
The D forum is also quite fast: https://forum.dlang.org/
Reminds me of bbPress, at least visually.
It makes me happy to see people still build stuff like this.
Also interesting that they host their code on Fossil, which itself has a builtin forum engine written in C.
https://www2.fossil-scm.org/home/doc/trunk/www/forum.wiki
Also interesting that they host their code on Fossil, which itself has a builtin forum engine written in C.
https://www2.fossil-scm.org/home/doc/trunk/www/forum.wiki
I don't understand — isn't the speed mostly limited by network or disk access? Is there a significant improvement by having the underlying code in Assembly?
A very cool application regardless, I haven't seen Assembly since college now.
A very cool application regardless, I haven't seen Assembly since college now.
yes, the speed is mostly limited by network/disk; no, there is no improvement from writing entire thing in assembly (optimizing a few hot functions is a different story)
I have not looked at this at this software in particular, but the few assembly web engines I have looked at in the past had worse performance that C versions due to making a much higher number of syscalls. For example, multiple send calls per response; lack of pool allocators; etc...
I have not looked at this at this software in particular, but the few assembly web engines I have looked at in the past had worse performance that C versions due to making a much higher number of syscalls. For example, multiple send calls per response; lack of pool allocators; etc...
You are right. The site is not fast because of Assembly, it is simply well designed.
Assembly, however, pushes towards healthier design choices. You have to keep things simple since you are the one who pays for the complexity, not a third-party library providers who use several third-party libraries themselves.
Assembly, however, pushes towards healthier design choices. You have to keep things simple since you are the one who pays for the complexity, not a third-party library providers who use several third-party libraries themselves.
The website being only 65kb in total size, all inlined with no additional downloads, plays a massive role in its performance no doubt.
Regardless of what language is serving up the request.
Still neat though.
Regardless of what language is serving up the request.
Still neat though.
That means it fits in cache in its entirety. I've found this often to be the biggest factor: reduce the size of the 'hot' set so it fits in cache and you can see crazy speed improvements.
[deleted]
if cpu is the bottleneck, then sure, if it's network/db then it won't make much of a difference at all.
> This is an engine for web based message board (forum) implemented entirely in assembly language, using FastCGI interface and SQLite database as a storage.
A lot of heavy lifting isn't even done in Assembly. Not to say anything of what it's using for a TCP stack. I don't know where in the Amdahl's distribution the assembly part falls, but I'm guessing it ain't much.
Edit: Also now that I perused the link, I wonder how many people commenting here are confused and are actually commenting on the speed of the Fossil browser vs the actual forum.
A lot of heavy lifting isn't even done in Assembly. Not to say anything of what it's using for a TCP stack. I don't know where in the Amdahl's distribution the assembly part falls, but I'm guessing it ain't much.
Edit: Also now that I perused the link, I wonder how many people commenting here are confused and are actually commenting on the speed of the Fossil browser vs the actual forum.
That depends. If you do more complex stuff you can easily be CPU bound, but if you're just pumping data then likely the network will be your first limit. Caching should take care of the disk as a limitation (besides that, SSDs are wicked fast).
What computationally complex operation would a forum application regularly do? I can't think of any but I've never written a forum application.
Deeply/truly threaded forums are definitely computationally intense. You have to leverage something to recreate the necessary tree from it's database structure (preorder tree traversal, adjacency lists, etc) while applying ACL methods, view transformations, etc on the dataset. This is much less of a problem nowadays though (compared to when forum software was "in vogue").
Database joins for instance. Ranking articles.
Wouldn't these happen in the DB?
I can see some algorithms for showing related articles being complex — but writing them in Assembly also invites other challenges (them being difficult to update and improve, concentrating on memory issues rather than algorithm, etc...).
I still think it's a cool project mind you.
I can see some algorithms for showing related articles being complex — but writing them in Assembly also invites other challenges (them being difficult to update and improve, concentrating on memory issues rather than algorithm, etc...).
I still think it's a cool project mind you.
Keeping any assembly codebase up and running, especially through changes in requirements is a massive challenge, requires extreme hygiene and will be very, very costly.
My largest assembly projects were around the 16K object code mark (the size of the largest EPROM) and I hope to never ever have to do stuff like that again. But the kind of performance you can get out of very modest hardware is amazing.
My largest assembly projects were around the 16K object code mark (the size of the largest EPROM) and I hope to never ever have to do stuff like that again. But the kind of performance you can get out of very modest hardware is amazing.
The DB in this case is SQLite, which is embedded.
Would that not still result in a disk IO bottleneck? Also, DB code is pretty well optimized. Are we sure that remaking that functionality in assembly will be dramatically better?
Figuring out which posts to display on page 853 in threaded view.
I can't think of a situation where that wouldn't be a slice of an array based on an integer post ID. Even with an embedded DB the IO should crush that gain, right?
> a slice of an array based on an integer post ID
Can't see how that works when you've got threading going on.
e.g. You have posts 1-10 and pages of size 5. 1, 2, 5 are top level posts. 3, 4 are replies to 1. 6, 7, 8, 9 are replies to 5. 10 is a reply to 2. Which means page 1 contains 1, 2, 3, 4, 10 and page 2 is 5, 6, 7, 8, 9.
Can't see how that works when you've got threading going on.
e.g. You have posts 1-10 and pages of size 5. 1, 2, 5 are top level posts. 3, 4 are replies to 1. 6, 7, 8, 9 are replies to 5. 10 is a reply to 2. Which means page 1 contains 1, 2, 3, 4, 10 and page 2 is 5, 6, 7, 8, 9.
Oh threading— yeah that's true. I still think of forums in the old school model.
Depends on the data structure. Since new replies may have to be inserted in tne middle, it may not be organized as a linear array.
(Oops, somehow I missed the existing discussion thread on this further down. Sorry for the repetition.)
Real-time notifications give a sense of activity, nice for building a community. Reminds me of http://listen.hatnote.com/ showing live wikipedia edits, but more integrated. Some anonymity, or mention of a group, e.g. anonymous users, forum member, admin, would be better. Too much and too specific sharing of activity makes this feel stifling--more like chat with read notifications, less like email or forum where people take time to compose replies.
Fantastic forum engine, the demo is https://board.asm32.info/ and beautiful themes are at https://asmbb.org
Got me thinking. How easy is it to write Assembly that looks good but is slower than C?
Like can you be really good with Assembly and still not be certain your effort is actually worth not doing it in a higher language?
Like can you be really good with Assembly and still not be certain your effort is actually worth not doing it in a higher language?
People do this all the time. The world is littered with assembly code written by people who believe that modern x86 uarches are just like the Pentium IV they cut their teeth on, or that an M2 is just a fancy Cortex-A53, meticulously hand ordering instructions while entirely missing the big picture.
If you’re going to take the trouble of writing assembly, you should do it right; figure out the fastest you can theoretically go, and see if you can get within a few percent of that without using assembly. If you can, stop. If not, figure out why you can’t, file compiler bugs as applicable, and then write assembly where it’s necessary. Re-measure, and if you aren’t within a few percent, figure out why not, then go back to step 1.
If you’re going to take the trouble of writing assembly, you should do it right; figure out the fastest you can theoretically go, and see if you can get within a few percent of that without using assembly. If you can, stop. If not, figure out why you can’t, file compiler bugs as applicable, and then write assembly where it’s necessary. Re-measure, and if you aren’t within a few percent, figure out why not, then go back to step 1.
If you're inclined to write fast code in assembly, you will. If not - not.
The thing is, optimizing compilers don't actually do any optimization in the classical sense. They don't do run-measure-modify loop as programmers do so all they can apply to the code is the heuristics some other programmers taught them. Some things are trivial like loop unrolling or function inlining. Some are not, like trigonometric approximations.
In the long run, when a compiler stops, a person goes further. That's why empirically, hand-made code is still faster than the compiled one. Of course you can write slow code in Assembly, but if you already decided to go low, you'll optimize your thing until satisfied with the result.
One particular thing comes to mind, C is ridiculously bad with automatic superscalarization (try VTune's HPC characterization on any code you like and see). Sure, you can use intrinsics and implement things manually, but that would be essentially the same as writing in assembly.
There is another contender though. Spiral (https://spiral.net/) that actually do solve the optimization problem can in fact be as effective as a human programmer and at a fraction of the cost. Spiral is overly specialized, so it's not a threat to all the HPC, but a more generic thing may indeed become a gamechanger.
The thing is, optimizing compilers don't actually do any optimization in the classical sense. They don't do run-measure-modify loop as programmers do so all they can apply to the code is the heuristics some other programmers taught them. Some things are trivial like loop unrolling or function inlining. Some are not, like trigonometric approximations.
In the long run, when a compiler stops, a person goes further. That's why empirically, hand-made code is still faster than the compiled one. Of course you can write slow code in Assembly, but if you already decided to go low, you'll optimize your thing until satisfied with the result.
One particular thing comes to mind, C is ridiculously bad with automatic superscalarization (try VTune's HPC characterization on any code you like and see). Sure, you can use intrinsics and implement things manually, but that would be essentially the same as writing in assembly.
There is another contender though. Spiral (https://spiral.net/) that actually do solve the optimization problem can in fact be as effective as a human programmer and at a fraction of the cost. Spiral is overly specialized, so it's not a threat to all the HPC, but a more generic thing may indeed become a gamechanger.
Trivially easy. Just try to beat a C compilers optimization for constant integer division.
https://clang.godbolt.org/z/MrMxo678x
https://clang.godbolt.org/z/MrMxo678x
Have you tried measuring the actual impact of this?
This optimization is so old, I'm not even sure if it's still worth the effort. It definitely worked in the 90s.
What you do here is you save on division, and lose on instruction cache. This might look good on a benchmark when all your code fits the cache nicely, but bite back in-vivo. You should try it out in an actual problem and see how it goes.
This optimization is so old, I'm not even sure if it's still worth the effort. It definitely worked in the 90s.
What you do here is you save on division, and lose on instruction cache. This might look good on a benchmark when all your code fits the cache nicely, but bite back in-vivo. You should try it out in an actual problem and see how it goes.
I know it's an appeal to authority, but if clang does it at high optimization levels then that's good enough for me to know it's faster.
Division is really really slow in CPUs, as I understand it. Like, CPUs are just awful at it.
It being an old opt doesn't mean it is invalid. I'm not aware of CPUs getting meaningfully better at division.
Division is really really slow in CPUs, as I understand it. Like, CPUs are just awful at it.
It being an old opt doesn't mean it is invalid. I'm not aware of CPUs getting meaningfully better at division.
You have to measure. It's a contextual optimization, no compiler in existence measures contextual optimization for you. Even the profile-based optimization is a spray and pray thing.
CPUs are not getting better at division per se, but they are getting better at all the ALU operations compared to the memory latency. You can add more transistors on a chip, but you can't cheat the light speed and make signal travel 30 cm in less than a nanosecond. So you need to bring your data closer, you need caches. Code, unsurprisingly, is also data, and it also goes through the instruction cache.
This optimization is instruction latency vs. cache intake. It may or may not be beneficial depending on the rest of the program. I've already seen both Clang and GCC produce faster code with -Os rather than with -O3.
CPUs are not getting better at division per se, but they are getting better at all the ALU operations compared to the memory latency. You can add more transistors on a chip, but you can't cheat the light speed and make signal travel 30 cm in less than a nanosecond. So you need to bring your data closer, you need caches. Code, unsurprisingly, is also data, and it also goes through the instruction cache.
This optimization is instruction latency vs. cache intake. It may or may not be beneficial depending on the rest of the program. I've already seen both Clang and GCC produce faster code with -Os rather than with -O3.
Add -O2 for even fewer instructions :)
Thanks, that was a silly oversight. Your comment is appreciated, as it saved an instruction in my game engine's JIT compilation :)
https://github.com/ArmageddonGames/ZQuestClassic/commit/0a78...
https://github.com/ArmageddonGames/ZQuestClassic/commit/0a78...
Cool!!
All I want for Christmas is the old-school :lol: emoji from phpBB days…
They still exist and are easily installable on current phpBB instances:
https://www.phpbb.com/customise/db/styles/smilies-13
https://www.phpbb.com/customise/db/styles/smilies-13
Not exactly a forum as we now know it, but I believe Bill Basham's Diversi-Dial (DDial) BBS software for the Apple II was written entirely in assembly. https://paleotronic.com/2019/09/28/diversi-dial-an-apple-ii-...
Imagine what you could do with a smartphone if it were programmed entirely in assembly.
You could make a device that was slower than Window CE and go bankrupt! https://news.ycombinator.com/item?id=36570062
Kolibri OS was written entirely in Assembly. I think the performance was pretty poor compared to C operating systems. Much easier to write optimized algorithms in high level languages.
https://kolibrios.org/en/
Why would anyone want to program a smartphone entirely in assembly?
There is a reason (well actually there are many) that the vast majority of software development these days is done using more advanced languages.
There is a reason (well actually there are many) that the vast majority of software development these days is done using more advanced languages.
Cost. Convenience. In that order.
Cost? Please explain why writing programs in assembly is supposed to be *cheaper* than writing programs in a higher level language? The same goes for convenience: Since when is writing an application in assemlby more convenient than writing an application in a modern language?
No, it is more expensive. And less convenient. For some reason you interpreted both of these the wrong way around. I wasn't answering the question, I was giving examples of those reasons. Which are pretty obvious.
Ah sorry, my bad! Makes a lot more sense this way ;-)
It certainly does :) I should have quoted that bit though to make it clearer.
How about security? I would never want an app written entirely in assembly to be allowed to take in arbitrary user input from the public internet.
Cross-platform support, which you might argue just falls under convenience, but if you're writing for a different CPU architecture, you've basically written 2 separate programs now and not one.
Cross-platform support, which you might argue just falls under convenience, but if you're writing for a different CPU architecture, you've basically written 2 separate programs now and not one.
>How about security? I would never want an app written entirely in assembly to be allowed to take in arbitrary user input from the public internet.
As opposed to one written in C, or a scripting language?
When you are coding every arithmetic operation by hand, it is trivial to detect e.g. integer overflows. And even produce the mathematically correct result for operations that temporarily overflow a 32/64 bit register.
(The exception is RISC-V, which seems designed exclusively as a target for C compilers and makes these operations more costly, thus guaranteeing that they won't be used even by compilers for safer languages)
Assemblers also won't remove any instruction you write because of reasoning about "undefined behavior". They won't change constant-time code into something that isn't.
There is a "soft limit" on the complexity of hand-written code, which encourages thinking more carefully about the design, and using data representations that are a good fit to both the problem and the machine.
Yes, all of that is more work, and requires specialized knowledge. But what I don't understand is why most programmers today think that is a bad thing?
As opposed to one written in C, or a scripting language?
When you are coding every arithmetic operation by hand, it is trivial to detect e.g. integer overflows. And even produce the mathematically correct result for operations that temporarily overflow a 32/64 bit register.
(The exception is RISC-V, which seems designed exclusively as a target for C compilers and makes these operations more costly, thus guaranteeing that they won't be used even by compilers for safer languages)
Assemblers also won't remove any instruction you write because of reasoning about "undefined behavior". They won't change constant-time code into something that isn't.
There is a "soft limit" on the complexity of hand-written code, which encourages thinking more carefully about the design, and using data representations that are a good fit to both the problem and the machine.
Yes, all of that is more work, and requires specialized knowledge. But what I don't understand is why most programmers today think that is a bad thing?
> Yes, all of that is more work, and requires specialized knowledge. But what I don't understand is why most programmers today think that is a bad thing?
Gotta love how when someone makes an wrapper around one feature of ffmpeg weighing over 100 MB, some say that's making great tools more accessible, and is saving the original dev so much time (and the gazillion people who will maintain it forever, because that's not the vanishingly small exception but the norm, The Thing That Must Be Planned For).
But when someone says the think making really tiny and bloat-free things by hand, and with 10x times the effort, the sky is falling, and people put more energy into denouncing what a human can achieve, vs. what modern compilers can do, than it would take to code the thing in brainfuck.
I think it's the corporate focus. Some people think doing something for money, and to multiply money, is intrinsically more "serious" than doing it for the love of it, or just for fun, and with no more of a goal in mind than skipping stones. And I think trauma plays a role, too: Someone mentions making a vanilla whatever (and it doesn't get more vanilla than assembly... it's the opposite of using a framework to be able to make 5 apps in 3 days), and people instantly come swarming to talk about the nightmare of inheriting that "code base".
Gotta love how when someone makes an wrapper around one feature of ffmpeg weighing over 100 MB, some say that's making great tools more accessible, and is saving the original dev so much time (and the gazillion people who will maintain it forever, because that's not the vanishingly small exception but the norm, The Thing That Must Be Planned For).
But when someone says the think making really tiny and bloat-free things by hand, and with 10x times the effort, the sky is falling, and people put more energy into denouncing what a human can achieve, vs. what modern compilers can do, than it would take to code the thing in brainfuck.
I think it's the corporate focus. Some people think doing something for money, and to multiply money, is intrinsically more "serious" than doing it for the love of it, or just for fun, and with no more of a goal in mind than skipping stones. And I think trauma plays a role, too: Someone mentions making a vanilla whatever (and it doesn't get more vanilla than assembly... it's the opposite of using a framework to be able to make 5 apps in 3 days), and people instantly come swarming to talk about the nightmare of inheriting that "code base".
> But what I don't understand is why most programmers today think that is a bad thing?
I think it's a bad thing because I disagree with you that you'll write fewer bugs because you're coding everything by hand. In my experience how much manual work you need to do correlates 100% with how many bugs the software will have.
I think it's a bad thing because I disagree with you that you'll write fewer bugs because you're coding everything by hand. In my experience how much manual work you need to do correlates 100% with how many bugs the software will have.
Weird. I just tried it and it seems to be bootlooping now.
Hmm. maybe there's a bug in one of the lines of someone's code.
Guess I better get started investigating it. 'Cause once I'm done I've got to start porting it to RISC-V.
Hmm. maybe there's a bug in one of the lines of someone's code.
Guess I better get started investigating it. 'Cause once I'm done I've got to start porting it to RISC-V.
Yeah, let’s leave it up to people to allocate registers, they are surely consistently good at it throughout whole code bases /s
In general, writing something in assembly won’t be faster. Some expert can in certain cases come up with a better hot loop in asm, but for larger scopes we can’t be as diligent as a machine can be.
In general, writing something in assembly won’t be faster. Some expert can in certain cases come up with a better hot loop in asm, but for larger scopes we can’t be as diligent as a machine can be.
Why would you be able to do more, or indeed less, with it programmed in assembly rather than a higher level language?
There isn't anything about assembly language that makes it inherently more effective or efficient than a high level language.
There isn't anything about assembly language that makes it inherently more effective or efficient than a high level language.
In principle, this amounts to giving a gift to society: the programmer spends more time on their work so that society as a whole consumes fewer resources.
Often, the opposite happens: the programmer transfers their productivity gain into an additional cost for society (usually by contributing to e-waste and added resource requirements).
It's easy to extrapolate this to other domains. Imagine that in order to enhance their productivity, aerospace engineers started buying off-the-shelf generic components and get them assembled as quickly as possible without seeking optimization. The airplanes will consume a lot more fuel, have a worse safety record and require constant upgrades and maintenance, but it doesn't matter much as the manufacturer can now hire fewer engineers, and it's other people's fuel you're wasting anyway.
I understand that seeking immediate profit is the norm, but I'm always a little disillusioned when I see selfless initiatives ridiculed.
It's easy to extrapolate this to other domains. Imagine that in order to enhance their productivity, aerospace engineers started buying off-the-shelf generic components and get them assembled as quickly as possible without seeking optimization. The airplanes will consume a lot more fuel, have a worse safety record and require constant upgrades and maintenance, but it doesn't matter much as the manufacturer can now hire fewer engineers, and it's other people's fuel you're wasting anyway.
I understand that seeking immediate profit is the norm, but I'm always a little disillusioned when I see selfless initiatives ridiculed.
I'm not sure how to make sense of this analogy without assuming that assembly language programming self-evidently produces superior programs than programming in high-level languages, and it's exactly that claim that the comment you're replying to is challenging.
Your executables will be a small fraction of the size that you expect, you will likely be able to fit the whole thing in cache and you will consume less power because you will be happy with a smaller cycles budget so you can run the cpu much slower.
Of course this all comes at a price: decreased programmer efficiency.
Of course this all comes at a price: decreased programmer efficiency.
I don’t think that’s actually true. Compilers write machine code that’s often much more efficient than anything you could think up by hand, and the bulk of the disk space/memory used by a modern executable is for resources/strings, not instructions. Stereotypical assembly code - extremely lean routines that accept minimal user input and don’t create human-readable output - is indeed smaller than a stereotypical compiled executable, but you’d have trouble beating the compiler 1:1 on the same problem.
But you won't be writing the same code as the code that you would write in a high level language, and that is sort of the point. You're going to do your utmost not to write such code because then you might as well break out the C compiler.
Assuming that such code is suitable or even feasible for the problem you're attempting to solve. High-level languages were created specifically for the purpose of writing large, complex software systems. We don't see assembly being used for those systems. Isn't there an argument that high-level languages are simply more fit for that purpose?
I don't think so, modern high level languages tend to be linked to huge runtimes that are usually load entirely in memory. Assembly programs don't.
> Your executables will be a small fraction of the size that you expect,
No they won't. There is no way that you can write more compact code than a modern optimizing compiler for anything except the most extreme edge cases.
No they won't. There is no way that you can write more compact code than a modern optimizing compiler for anything except the most extreme edge cases.
Yes you will. Because you can't afford to write code like a modern optimizing compiler. You're going to have the same kind of linecount that you have in your high level language projects and those lines will compile down to a few bytes each at most.
Assembly language binaries tend to be extremely small compared to equivalent code written using a high level language. But: you'll easily spend 10x the time on them. The 'modern optimizing compiler' argument is at the function level: where you write a function using assembly and then write a similar function using a high level language (but still a compiled one, obviously). Yes, the compiler will probably win that race. But an assembly language programmer isn't going to write their code like that at all.
They will reduce the task to the point where it is manageable and that alone will save far more code than the compiler can ever remove. Assembly is (and assembly language based applications are) utterly bloat free, you do what you have to do and nothing more. You can use registers in ways that a compiler would never even think of because you can globally optimize.
No stack frames if you don't need them. No memory accesses if you don't need them.
But code that is hard to maintain and that likely will not be easy to work on with multiple people. 100 KLOC (including comments) -> 16Kb output. No high level language would even begin to approach that.
Assembly language binaries tend to be extremely small compared to equivalent code written using a high level language. But: you'll easily spend 10x the time on them. The 'modern optimizing compiler' argument is at the function level: where you write a function using assembly and then write a similar function using a high level language (but still a compiled one, obviously). Yes, the compiler will probably win that race. But an assembly language programmer isn't going to write their code like that at all.
They will reduce the task to the point where it is manageable and that alone will save far more code than the compiler can ever remove. Assembly is (and assembly language based applications are) utterly bloat free, you do what you have to do and nothing more. You can use registers in ways that a compiler would never even think of because you can globally optimize.
No stack frames if you don't need them. No memory accesses if you don't need them.
But code that is hard to maintain and that likely will not be easy to work on with multiple people. 100 KLOC (including comments) -> 16Kb output. No high level language would even begin to approach that.
> They will reduce the task to the point where it is manageable
If they don’t even solve the problem, then it is no competition.
If they don’t even solve the problem, then it is no competition.
It's trivially easy.
One low hanging fruit: Compilers are handicapped by ABIs and language semantics, they must adhere to calling conventions, alignments, paddings, exceptions/stack unwinding, etc.
If you don't have to care about any of that you can save a lot of useless instructions.
And secondly when it comes to size optimizations, compilers are pretty bad (or they tend to still value some speed over pure size). Wont find any modern compiler emitting lodsb/stosb (the non-rep kind) on x86 for example.
One low hanging fruit: Compilers are handicapped by ABIs and language semantics, they must adhere to calling conventions, alignments, paddings, exceptions/stack unwinding, etc.
If you don't have to care about any of that you can save a lot of useless instructions.
And secondly when it comes to size optimizations, compilers are pretty bad (or they tend to still value some speed over pure size). Wont find any modern compiler emitting lodsb/stosb (the non-rep kind) on x86 for example.
> Compilers are handicapped by ABIs and language semantics, they must adhere to calling conventions, alignments, paddings, exceptions/stack unwinding, etc.
I believe most of these are only at potential “extern C” points. Usually these conventions are upheld because they don’t have a huge cost, but to give you a trivial example: inlining is literally about dropping all that in favor of optimizing at a larger scope.
I believe most of these are only at potential “extern C” points. Usually these conventions are upheld because they don’t have a huge cost, but to give you a trivial example: inlining is literally about dropping all that in favor of optimizing at a larger scope.
I remember claims that compilers are going to emit better machine code than humans when pipelined and speculative execution was first implemented in intel processors.
It turned out to not be true.
It is still not true as of today. Humans are still better at this, and still by humongous margin. LLMs are going to change that soon however.
Lol at both of these claims.
Humans are better at tiny hot loops. Not at all at anything larger than that.
And call me back once LLMs successfully solve a Sudoku first, before they attempt at spewing out code.
Humans are better at tiny hot loops. Not at all at anything larger than that.
And call me back once LLMs successfully solve a Sudoku first, before they attempt at spewing out code.
Rather than argue about it, why don't you find an equivalent demo bit of code in both ASM and any other language you choose, and compile both into a static (no linking of libraries) binary?
You should be able to use the Rosetta Code web site to find equivalents written in ASM and say, Rust or C++... then you can easily demonstrate that what you say is factually correct.
You should be able to use the Rosetta Code web site to find equivalents written in ASM and say, Rust or C++... then you can easily demonstrate that what you say is factually correct.
Surely we are talking about real applications not toy educational snippets. Or are you claiming that what works for the dozen or so lines in a typical Rosetta code example works just as well for million line, multi-user, multithreaded, object oriented simulators and optimizers of electrical machines?
At risk of moving the goal posts, I suspect that actually writing such a program in assembler might well be impossible simply because it would probably take too long to write and debug.
If assembler tooling were improved perhaps this could change but who will do it. There have been assemblers with object oriented extensions, perhaps other developer aids could be created. But who will expend the effort?
At risk of moving the goal posts, I suspect that actually writing such a program in assembler might well be impossible simply because it would probably take too long to write and debug.
If assembler tooling were improved perhaps this could change but who will do it. There have been assemblers with object oriented extensions, perhaps other developer aids could be created. But who will expend the effort?
Many instructions in assembly is simply “logistics” of where should this or that byte go. Machines are eons better at it at large scopes than humans, you surely don’t have enough hair to sit through and carefully examine every register. Also, will you decide on a case by case basis to “inline” a function’s body? What if the function’s body changes? Will you go back to every “inlined” part? What if that makes a more efficient register allocation possible, rewrite the whole function where the inline happened?
I’m sure it would be very fast at booting and fast at crashing as well. However, on the Android side it’s probably what’s needed to compete with Apple hardware and software.
The real problem is that I don't control all the code.
If I had millions of person-hours to RE all the apps I hate, I'd just write them in Rust or something.
If I had millions of person-hours to RE all the apps I hate, I'd just write them in Rust or something.
assembly? the current standard is kotlin or swift which while reasonably performant, leave a lot on the table. i'd love to have first class support for writing android and ios applications in rust. plenty fast enough for me. my day job is elixir but the memory requirements are a bit high for mobile apps (though I'm sure the guys at nerves would disagree)
Didn't we have something similar to that with the early DOS-based palmtop PCs?
Very fast! Or should I say, the normal speed at which websites should operate.
x86 only.
x86 only.
[deleted]
I looked into maybe using this a few months ago, but decided against it.
https://board.asm32.info/hi-johnfound-welcome-back.351/#1624...
https://board.asm32.info/hi-johnfound-welcome-back.351/#1624...
What the hell are those god-awful notifications that keep spamming the bottom right corner of the page? I can't seem to turn them off.
Would be fine if they didn’t cover the content on the page, but maybe that’s a mobile problem.
There's a bell icon in the header, it toggles the real-time notifications. Took me a minute to find it too.
I went straight to ublock element picker without thinking about it
board.asm32.info##div.info.toast
board.asm32.info##div.info.toast
While this is mainly a technical discussion forum, I am a bit disappointed to see the comment linking to the author’s political views posted on their own forum as being flagged. This is relevant information for people deciding whether to support, use, or be affiliated with this project.
Agreed. That comment doesn't seem to break any rules. Is "flagged" something that just means enough people downvoted it, or does it require moderator intervention?
[deleted]
I just checkout out the chat functionality and the first thing I saw there was a a bunch of obscene racists messages in Russian.
Thanks for posting. In the .Net world we had the whole Moq library drama recently. Now I check the social media of library creators before I use the library. I'm sorry but I cannot trust deranged people's code in production systems.
Ugh, yeah. That's unfortunate.
to each his own, but I can't really use a computer without implicating myself with software written by people with totally different ethics/philosophy/politic than myself; in fact I think that no one can.
if you find a software stack that aligns itself perfectly with any single dogma (outside maybe TempleOS) then let me know, but right now that seems like a pipe dream.
I mean, just as food for thought, is there any common-use cryptography without major ties to war parties and national security groups?
aside: I can think of plenty of more practical reasons to avoid a net-facing forum software written in asm in 2023.
if you find a software stack that aligns itself perfectly with any single dogma (outside maybe TempleOS) then let me know, but right now that seems like a pipe dream.
I mean, just as food for thought, is there any common-use cryptography without major ties to war parties and national security groups?
aside: I can think of plenty of more practical reasons to avoid a net-facing forum software written in asm in 2023.
I don't think it's a black-or-white thing. You weigh pros and cons. Linus can be a bit of a jerk but the Linux kernel is immensely useful to me, so I use it in spite of some misgivings. This software, on the other hand, is mostly a fun curiosity and the author is promoting actual genocide. So in this case I'll say no thanks.
It's an indication that someone can be a good programmer while still lapping up Putin's propaganda.
On a related note, I somewhat recently posted just the link to the very religious SQLite ethics page on Facebook - which immediately flagged it as some objectionable something or other. Just a link to a web page of one of the most popular open source packages on the planet which Facebook itself no doubt uses. They're so incredibly leftist that their algorithms can't even abide linking to a religiously oriented page.
On a related note, I somewhat recently posted just the link to the very religious SQLite ethics page on Facebook - which immediately flagged it as some objectionable something or other. Just a link to a web page of one of the most popular open source packages on the planet which Facebook itself no doubt uses. They're so incredibly leftist that their algorithms can't even abide linking to a religiously oriented page.
[deleted]
veavo(9)
Garbage collecting interpreters are (mostly) for wimpy scripting kiddies. The obvious historically documented exceptions are the "Symbolic AI Researchers."
In 1990, SQL (and dBASE and Excel) was a "computer language" for secretaries. Now in 2023, we suffer uneducated halfwits manically typing in endless repugnant "ad tech" and "SEO" with our "Bioinformatics Researcher" hacks inflicting delusions based on Excel #Err cells (look it up) upon an unwitting populace.
Somewhere, we went wrong. We have GREAT and WISE Software Engineering (Prescriptive and Historical) guidance available in the public domain now. Our mercenary "job hoppers) don't seem to be interested in accessing that.
Going forward, some combination of ASM and Forth in Open Source incarnations and with type-checking hints will wring the most computation out of energy resources (CPU cycles).
In 1990, SQL (and dBASE and Excel) was a "computer language" for secretaries. Now in 2023, we suffer uneducated halfwits manically typing in endless repugnant "ad tech" and "SEO" with our "Bioinformatics Researcher" hacks inflicting delusions based on Excel #Err cells (look it up) upon an unwitting populace.
Somewhere, we went wrong. We have GREAT and WISE Software Engineering (Prescriptive and Historical) guidance available in the public domain now. Our mercenary "job hoppers) don't seem to be interested in accessing that.
Going forward, some combination of ASM and Forth in Open Source incarnations and with type-checking hints will wring the most computation out of energy resources (CPU cycles).
That’s a thoroughly uninformed take, and this stance is overly elitist for no good reason.
All I can say is good luck with that philosophy in anything other than writing drivers or small embedded systems.