flat assembler
Message board for the users of flat assembler.

flat assembler > Heap > Why do YOU love assembly?

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
moveax41h



Joined: 18 Feb 2018
Posts: 47
This forum's description says "anything not related to assembly language programming," however, this is an editorial so I didn't feel that it was right to post it in the Main forum. Moderators, if you disagree, feel free to move it.

Tell us why you love assembly language.

For me, assembly language has a very special place in my heart. I began programming at age 11 using PHP, Python, and C++. PHP was at version 3 or 3.5 I believe back then. After a few years, I put programming down and took up others things, as well as continuing my education.

After a few other careers didn't work out, one day I decided to start programming again and realized that I loved it and this was the career for me. However, as a kid I was unlike other kids in that after school, I would always be reading howstuffworks.com, books like Basic Electricity, physics, and mathematics. I was obsessed with knowing how things worked at the deepest and most atomic levels. Little did I know that I would make a carer out of it way later in life by becoming a software reverse engineer. I somehow made career out of doing what I loved as a kid. I've owned TVs my whole life but they've done nothing but collect dust and stay off most of the time!

As an adult programmer, I was not satisfied by high level languages... I'm not a huge fan of abstraction although I recognize the necessity of it in modern applications. I ALWAYS want to know the implementation details... I wanted to know how strcpy worked, what objects really were, what the stack really was, what the heap really was, how the kernel interacted with drivers to control hardware, etc... I love low-level programming.

This took me to assembly language. To me, assembly language is very powerful and so much fun. I love playing with binary numbers, bits, and bytes. I love the fine-tuned control that assembly language affords, and knowing exactly how the CPU works. I also view assembly as a true art and I feel that humans and compilers have only discovered like 5% of what assembly really has to offer.

_________________
-moveax41h
Post 21 Jul 2018, 05:15
View user's profile Send private message Reply with quote
Ali.A



Joined: 08 Jan 2018
Posts: 124
i didnt read your full post, anyhow .. if i would describe asm and it meaning in my life it would take a very very very long time. (maybe 24hrs writing without a break)

but to make it short, read my signature. (adding extra word "philosophers")
and welcome to asm world.

_________________
Asm For Wise Humans
Post 21 Jul 2018, 06:35
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6964
Location: Kraków, Poland
moveax41h wrote:
I ALWAYS want to know the implementation details... I wanted to know how strcpy worked, what objects really were, what the stack really was, what the heap really was, how the kernel interacted with drivers to control hardware, etc... I love low-level programming.
I believe this is a very valuable approach and even if one is going to stick with high-level languages, the knowledge of the underlying architectures really pays off.

moveax41h wrote:
I love the fine-tuned control that assembly language affords, and knowing exactly how the CPU works.
I would say that this is what was always the main appeal of assembly languages to me - it gives you that feeling of "being in the driver's seat" and having everything under control.

I see some similarities between assembly programming and sailplane gliding - another thing I really liked, perhaps they both appealed to the same yearning. In a glider you feel you're completely on your own, with some very basic tools that you have to deeply understand in order to use them effectively. And that knowledge gives you an unique sense of control.
Post 21 Jul 2018, 09:25
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1258
Tomasz Grysztar wrote:
moveax41h wrote:
I ALWAYS want to know the implementation details... I wanted to know how strcpy worked, what objects really were, what the stack really was, what the heap really was, how the kernel interacted with drivers to control hardware, etc... I love low-level programming.
I believe this is a very valuable approach and even if one is going to stick with high-level languages, the knowledge of the underlying architectures really pays off.
For me, personally, I learned asm precisely because I wanted to understand some concepts that are very poorly explained in HLL books and "abstracted away" with silly analogies. For example, pointers. So in fact my original goal for learning asm was for understanding HLL concepts better...

But now I became obsessed with knowing how every little thing works, even when I look at HLL code. If it's a HLL project I write from the start (not e.g. contributing to some other project), I always use something like -nostdlib because I don't want junk pulled into my project. I want to control the entry point and so on, assembly kind of "spoiled" me in this regard. I do use some standard library APIs sometimes, but just as normal libraries, not statically linked to my application/lib.

I also have an obsession with overusing inline asm even in HLL code (inline asm is best thing about GCC Razz), or writing some functions purely in FASM even if the main project is HLL-based (and not necessarily because I profiled them to be slow, but more than that).

I kind of hate polluting my code with unoptimized crap (i.e. most static linking falls into this) even when using HLLs, unless it's for development/internal use only. I've no problem using libraries that are somewhat bloated, though, because I always justify it as "they are shared libraries so it's ok for them to be more generalized than specialized for my application" in my mind... otherwise I go crazy with the bloat in my code. Yeah sort of an obsession. Confused For example, I hate static linking printf, but dynamic linking to it is ok.
Post 22 Jul 2018, 19:33
View user's profile Send private message Reply with quote
jazz



Joined: 16 Jul 2016
Posts: 59
I love ASM because it makes my head hurt so much that writing in C/Delphi/Lisp - my usual go-to languages - feels like a long, chilling holiday afterwards.

Oh, and because I hate software that hogs half a gigabyte of RAM doing nothing... and I want to do it better.
Post 25 Jul 2018, 21:11
View user's profile Send private message Reply with quote
moveax41h



Joined: 18 Feb 2018
Posts: 47
jazz wrote:
I love ASM because it makes my head hurt so much that writing in C/Delphi/Lisp - my usual go-to languages - feels like a long, chilling holiday afterwards.

Oh, and because I hate software that hogs half a gigabyte of RAM doing nothing... and I want to do it better.


Tell me about it. I cannot for the life of me even ponder to understand how on earth it's currently ok for a CHAT ROOM PROGRAM (cough cough SLACK) or a web browser with 25 tabs of text and images open to take 6 GIGABYTES of active RAM.

It's just unbelievable because both of those problems have been solved like 40 years ago. But that's a rant for another thread. I enjoy reading everyones reasons.

_________________
-moveax41h
Post 25 Jul 2018, 23:16
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1258
moveax41h wrote:
Tell me about it. I cannot for the life of me even ponder to understand how on earth it's currently ok for a CHAT ROOM PROGRAM (cough cough SLACK) or a web browser with 25 tabs of text and images open to take 6 GIGABYTES of active RAM.

It's just unbelievable because both of those problems have been solved like 40 years ago. But that's a rant for another thread. I enjoy reading everyones reasons.
Yeah, fully agreed. I think things are overbloated out of hand these days. It's so bad that I cannot even imagine how it can possibly use that much memory, unless it's made to waste memory on purpose. Seriously, I just can't.
Post 30 Jul 2018, 20:24
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16051
Location: 112 Ocean Avenue, Amityville
Furs wrote:
Yeah, fully agreed. I think things are overbloated out of hand these days. It's so bad that I cannot even imagine how it can possibly use that much memory, unless it's made to waste memory on purpose. Seriously, I just can't.
You might be thinking of the "garbage collector". It means the programmer never has to free memory, ever. And naturally it works perfectly, NOT.
Post 30 Jul 2018, 21:19
View user's profile Send private message Visit poster's website Reply with quote
moveax41h



Joined: 18 Feb 2018
Posts: 47
revolution wrote:
Furs wrote:
Yeah, fully agreed. I think things are overbloated out of hand these days. It's so bad that I cannot even imagine how it can possibly use that much memory, unless it's made to waste memory on purpose. Seriously, I just can't.
You might be thinking of the "garbage collector". It means the programmer never has to free memory, ever. And naturally it works perfectly, NOT.


And of course it's always way more secure and there can't be any memory corruption. Smile

_________________
-moveax41h
Post 30 Jul 2018, 22:12
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 418
Location: Belarus
Garbage collection is what decreases the minimal level of professionalism o a programmer to the ground, so we’d all better just shut up and start writing the same crap Smile Don’t look for any sense in the phrase.
Post 31 Jul 2018, 10:41
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2309
Location: Usono (aka, USA)
It's too hard to express what I feel here. I've already scrapped one long post days ago. Long story short ....

I don't prefer assembly anymore (except for fun). Well, I'm a DOS fan (luddite), so being incompatible with modern Windows and Linux (plus the prevalence of things like Android atop ARM) makes me prefer portable code, even if HLLs are notoriously bad and sloppy regarding true portability (which should be one of their strengths, but it's much harder than it sounds and nobody cares). Yes, I know, you can have some portability with assembly (like FASM), but's it's also hard.

If I had to go back in time, I'd rather learn Turbo Pascal or Oberon (first) rather than x86 assembly. Obviously, with a smartlinker, the problems of bloat aren't as bad. But even without, you can workaround such problems if you're diligent enough. I feel like there are enough bigger problems to solve than just worrying about every last cpu cycle or byte of RAM or disk space (even if I agree that we shouldn't be lazy or wasteful). I think learning good algorithms and such or avoiding common high-level pitfalls are probably worth more attention than cpu instruction minutiae. Then again, with CPUID and a billion extensions and tons of barely-compatible cpus (of various ages that still function, thus shouldn't be thrown out nor abandoned), I think assembly can be crucial. But overall, lowest common denominator (generic code from generic compiler) is often "good enough" (begrudgingly).

But I'm not as experienced in assembly as some people, nor am I a Comp. Sci. professional or engineer. So limited skills means my efforts aren't up to snuff. I'm sure somebody can do brilliant things in assembly, but it ain't me. My point is that simplicity, elegance, minimalism are all virtues that can be cultivated outside of any specific OS or programming language or tool. I feel like you can learn and be successful despite any language. Of course, some languages are better than others for certain tasks. Use the right tool for the job. Heck, pre-made (canned) solutions can sometimes be combined to avoid rewriting everything from scratch (although I still think bootstrapping from scratch is a noble, yet often ignored, goal).

Bad tools can still produce good code, creating good solutions to common problems (and vice versa). A poor carpenter blames his tools, but I do feel like "x86 only" (or "AMD64 only") is a dead end. Backwards compatibility (in x86, binary compatibility) and supporting legacy is a noble goal, but at this point, nobody cares or it's just too much work. So I feel like we're drowning (or rebeling?) against such things. Too many incompatible machines exist nowadays, which causes modern developers to only tend to focus more on high-end (sadly) instead of low-end cpus. Ignoring complexity entirely or denigrating working legacy machines is bad, IMHO.

As bloated and heavyweight as HLLs are, they don't have to be. They do indeed perform a useful function (if used wisely). But I think they should be simplified. But it's not easy making things simple. It takes a genius (or heavy experience?) to minimize, isolate, reduce, simplify without breaking anything or omitting useful features or being hard to use. I don't think x86 assembly directly encourages that. I think it's some urge or necessity beyond the language or tool itself. Certainly I'm not recommending OberonOS or DOS to modern people, but certainly even those OSes can be useful in a pinch (or under VM) for specific tasks. Not every problem needs a billion-dollar OS as its solution, nor does everything have to be written in C++17.

SUMMARY:
So is assembly a panacea? No, but neither are HLLs. The true goal is to focus on portability, simplicity, legibility, maintainability, elegance, minimalism, flexibility, provable correctness, liberty, etc. No tool is off limits (although the less arcane / archaic, the better).
Post 13 Aug 2018, 19:36
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2309
Location: Usono (aka, USA)
But I don't think HLLs by themselves waste a lot of RAM in bloated code generation. The RAM usage is usually related to (dynamic?) data, not code. I know you're not naive, but I don't know how you think assembly automatically fixes that. Sure, it forces you to know what you're doing behind the scenes (unlike C++, perhaps?), thus avoiding accidentally misusing costly algorithms.

I do blame AMD64 as part of the problem since it treats memory as unlimited. With old IA-32, you knew that a gig was a lot of memory, and you avoided trying to use it all. But nowadays nobody cares because they can just buy / install more, ad infinitum. That breeds laziness (although I'm sure it's harder than it sounds to be RAM efficient).

FYI, in case it wasn't obvious from my other posts, OberonOS has been ported to Spartan Xilinx FPGA. The entire OS, with compiler self-hosting, can run in only a single meg of RAM. And yes, it's garbage collected and even native code (no VM, JIT, bytecode). Maybe that's not impressive to you because it omits so much, but the point is that garbage collection isn't always bad or inefficient.

It's good to care about optimizations, algorithms, improving things, finding better solutions. But I think it's a mistake to lean too heavily on any tool or OS or language as if it is somehow superior, "in all ways", to everything else. Someone mentioned "web browser with 25 tabs", but there are plenty of alternatives, they just don't do literally everything and the kitchen sink. GNU Emacs is bloated as hell, but it does a ton. You don't need to leverage all of that for every little text edit you make. *nix in old days was focused on "doing one thing (only) and doing it well". Sometimes I think we complicate and add too many features to our software. ("You ain't gonna need it", "keep it simple, stupid", "don't repeat yourself", "write one to throw away" ... you know, relatively common wisdom being thrown around in certain circles.) See what I mean?
Post 13 Aug 2018, 19:48
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1258
Well I love C/C++ as much as asm, but the problem is with most other HLLs, they just can't be "tamed". It is undeniable that at some point it will add bloated instructions, regardless of how good the compiler is, because it simply cannot know that (until runtime).

For example, even low level languages like Rust will forcefully enable bounds checking (which ironically makes them more vulnerable to Spectre even if the code is perfect), even though it doesn't have garbage collector. So, the bloat is unavoidable, not due to compilers not being smart enough, but due to the language itself. (in Rust you can use unsafe blocks but well, nobody does that often, hence the reason of bloat)

C/C++ are special because you can, theoretically, make really transparent HLL abstractions in terms of code generation. There are some exceptions though, where you'll need compiler extensions (or plugins). Most HLLs, however, just suck because they'll forever generate bad code due to their design.

Don't get me started on garbage collected languages (e.g. D, Go). Sometimes large memory use is the fault of the language, and in this case, their integrated garbage collectors.


BTW speaking of Pascal, I don't know why but I just can't "get" into it. Everytime I see .pas files from some open source software, I cringe, because reading it looks so heavy to me. I mean the language text itself feels bloated, not the output. It's like Lisp with parentheses weirdness, but this time it's just too much heaviness from overuse of words. However the one language that's worse to read is Haskell. It's like hieroglyphs.
Post 14 Aug 2018, 11:59
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2309
Location: Usono (aka, USA)
Furs wrote:

BTW speaking of Pascal, I don't know why but I just can't "get" into it. Everytime I see .pas files from some open source software, I cringe, because reading it looks so heavy to me. I mean the language text itself feels bloated, not the output. It's like Lisp with parentheses weirdness, but this time it's just too much heaviness from overuse of words. However the one language that's worse to read is Haskell. It's like hieroglyphs.


There are too many dialects and derivatives. That alone makes things very hard to understand. It's considered in the Algol line, thus directly inspired by Algol 60 (and -W, unofficially) but not 68, but it also had improvements, successors, and unofficial derivatives. So you have to contend with classic, Extended, Turbo, Delphi, and many more! Not to mention Modula-2, Oberon (both with many dialects: PIM2, PIM3, ISO ... -1, -2, -07, Component Pascal, Active, Zonnon) and various others like Modula-3, Turing, Ada, Oxygene.

Most code is naive or throw-away, so you'll see functions that are too long, not enough use of separate modules (units), esp. for non-portable "system" stuff. In other words, not enough abstraction or encapsulation. (I hate to be that guy, but it's true.) And FPC itself (or even GPC) allows you to mix dialects (which is brittle but can be useful) although truly FPC started as TP-only and eventually became Delphi-obsessed. Yes, FPC mostly supports "ISO" (7185) nowadays, but it's very rare. Most Delphi code is Win32 specific, and most old TP code is DOS specific (with too much use of inline asm).

So compatibility is a nightmare, even if FPC does wonderfully (for the most part). I like comparing various dialects, but newcomers are intimidated into only following the "newest, greatest, most powerful" one, i.e. Delphi (dialect), which was (until relatively recently) mostly focused on Windows only. Like I said, even FPC went Delphi crazy since 2.0.0, released in 2005, so there's no great excuse for me to not embrace it (although it's bizarrely different). Even Turbo dialect bears little relation to Delphi anymore.

I guess I'm just slow and stubborn for not immediately jumping on the latest fad / craze. I'm too simple, so I need simplicity. Delphi and FPC are the only obvious big choices nowadays (although of course others exist, too). For Oberon, you'll usually only see oo2c (-2) or obc/Oxford (-2, now also -07), esp. in *nix distros. For Modula-2, GNU gm2 (ISO 10514) still isn't in GCC trunk (yet), but it's very stable and still being updated. And of course Ada/GNAT is still kicking (but I never truly learned it) with its own dialects ('83 [obsolete], '95 [OOP! most popular?], '05, '12).

SUMMARY:
My point is that it depends on what dialect the code you're trying to read was written in. Usually it's non-portable code, so I wouldn't take that as a good example (esp. if abandoned, obsolete, etc). I guess you need to look at simpler, more high-level code, to get a good picture of what is supported and why, at the simple level. Dialects and portability make a huge difference. But honestly you don't need to know everything (or anything?), it's just trivial details. It's not that you're missing out on any brilliant ideas (for the most part), just slight differences in how things are done. Pascal does have some virtues over C or even C++, but it's not necessarily enough for you to throw everything else away. The common wisdom is to only learn new languages to see how to do things differently. That experience does come in handy, even if you don't use those languages anymore later on.
Post 14 Aug 2018, 20:40
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 418
Location: Belarus
There’s still one thing that makes Pascal better than most languages nowadays: String is made first-class citizen. It’s funny how a whole bunch of languages derived from C have strings behave in strange ways (from the point of view of hypothetic someone not “spoiled” by deep knowledge of different ways to implement them).

I mean, it’s necessary to know how your types work but having a type behave in an high-level and consistent way (compare with C++: str + "abc" vs "abc" + str) is what actually makes programming the process of solving a task, instead of fixing the language design mistakes.
Post 14 Aug 2018, 22:13
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2309
Location: Usono (aka, USA)
DimonSoft wrote:
There’s still one thing that makes Pascal better than most languages nowadays: String is made first-class citizen. It’s funny how a whole bunch of languages derived from C have strings behave in strange ways (from the point of view of hypothetic someone not “spoiled” by deep knowledge of different ways to implement them).

I mean, it’s necessary to know how your types work but having a type behave in an high-level and consistent way (compare with C++: str + "abc" vs "abc" + str) is what actually makes programming the process of solving a task, instead of fixing the language design mistakes.


I assume you knew some (or all?) of this. Actually, I assume you're mostly referring to Delphi.

C didn't include strings in the language proper because it complicated the grammar. But classic Pascal did have "packed array [1..n] of char" (built-in because obviously it didn't have headers/libraries). Extended Pascal had proper strings and schemata arrays. Actually, classic Pascal (sometimes) had conformant arrays. PIM Modula-2 lacked strings except via external modules, but Oberon added some support back in the grammar (now always ending in NUL). ISO Modula-2 had string concat operator, similar to Turbo Pascal. I think UCSD was the first Pascal dialect to implement strings. Turbo had (up to) 255-byte proper variable strings. Extended was often limited to either 32000 or 64000 bytes (depending on implementation). I assume you're thinking more of Delphi's huge / ANSI strings, which are reference-counted and on the heap, thus much larger capacity. Delphi also has dynamic arrays (using exceptions behind the scenes) while Modula-2 only had open arrays (vs. conformant). Oberon-2 added "POINTER TO ARRAY OF CHAR" for dynamic strings via heap. Oh, and while I never truly learned Ada, it had strings (although wasn't "unbounded" only introduced in '95?). Of course, Ada had '&' string concat. Even Modula-3 [sic] had that, but their TEXT type was read-only, heap-based, garbage-collected strings.

Yeah, it's complicated. I don't claim to fully understand it all! My point is that it varies not just by language but also by dialect. It's impossible to treat them all similarly, even at the simplest functionality. It's quite a mess, actually. But most people don't know or care about obscure dialects. For "Pascal", you really only have to worry about Delphi these days. (Moria was written in VAX/VMS Pascal, "varying of char" or whatever, but even that was long ago ported to C for U(nix)Moria. But I think one fork called BOSS was also translated to FPC a few years ago.)

Yeah, I wasted too much time investigating obscure dialects. Laughing
Post 17 Aug 2018, 07:16
View user's profile Send private message Visit poster's website Reply with quote
Picnic



Joined: 05 May 2007
Posts: 1256
Location: Underwater
The fact that is a short language with no data types, it has registers and the memory, enough to make everything. I love that.
Post 17 Aug 2018, 07:47
View user's profile Send private message Reply with quote
Coty



Joined: 17 May 2010
Posts: 545
Location: ␀
The thing I like about assembly is that it is raw, I can manipulate bits and bytes however I want and whenever I want, I don't have to worry about how I need to make my string an int, or a byte or vise versa or whatever, I can can just point at binary and flip bits as I so chose. as long as I don't try some crap like

mov al, dword

then I'm fine. But HLLs... especially the ones I tend to use get all stuffy and I have to end up writing sub routines with over 30 lines to convert my data around just so I can flip a bit, then call another routine to put it back.

... I also like that it's straight forward, as a guy who uses allot of different languages, you would be surprised how often i forget how to do a for loop in X language. But not for assembly lol

_________________
http://codercat.info/
http://codercat.org/
Post 19 Aug 2018, 18:35
View user's profile Send private message Send e-mail Visit poster's website AIM Address Reply with quote
praddo



Joined: 09 Oct 2011
Posts: 10
Elegance, power and control.
Post 19 Aug 2018, 19:30
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2309
Location: Usono (aka, USA)
It's too vague. "Assembly" can mean many things.

What cpu (i686 or x64 or AVX-512 or ARMv8)?
Raw or high-level (preprocessor, macros, structs)?
What APIs (DPMI, Win32, SDLv2 or GTK or whatever)?
What calling convention (cdecl vs. stdcall)?
What linker (if any)?
What host and target OSes (Bash vs. Powershell vs. CMD vs. TCC, among other native tools)?
Are Makefiles needed (or what alternative build system)?
What third-party dependencies (libraries or tools that aren't pre-installed)?

And even all of this assumes you know good algorithms. So assembly won't help if you don't understand heapsort vs. mergesort or dynamic memory usage or buffering I/O or whatever. (I don't really, that's why I mention it! But I'm no pro anyways.)

Maybe some things are too easy, too obvious, for some of you. Or maybe it's not relevant or important enough for your projects. I'm just saying, in general, it can be very overwhelming and complicated, even for simple commandline userland apps that don't do any heavy lifting. Don't overestimate how "simple" it truly is. We have to strive for greater simplicity because everything is already brittle, and there's only so much a novice can handle. Not everyone is an engineer who can dynamically patch their kernel, rebuild world from scratch, or solder a board.
Post 20 Aug 2018, 14:53
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2018, Tomasz Grysztar.

Powered by rwasa.