flat assembler
Message board for the users of flat assembler.

Index > Heap > Serious assembly programming

Goto page Previous  1, 2, 3, 4  Next

Do you work on some pure assembly project?
Rather big project.
38%
 38%  [ 14 ]
Middle to small project.
27%
 27%  [ 10 ]
Small, educational programs.
27%
 27%  [ 10 ]
I have some ideas, but no time, knowledge, etc.
5%
 5%  [ 2 ]
Total Votes : 36

Author
Thread Post new topic Reply to topic
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
None of my friends are coders, just a bunch of end users. (all 2 of them)
When i talk about asm optimizations they laugh at me and ask why for?
The dont care that Adobe takes a few seconds to load its plugs.
They only seem to care that a GlueTube video buffers fast enough.
But for interactive (games and stuff) they sure would cry about framerates.
The way i see it, smaller is always better, but fast only required in some places.
So the way i see it, use the tools that get the job done in fair amount of time.
When performance is needed, then spend extra time to work it out...
Post 14 Jun 2011, 18:39
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
My experience says that if you optimize for size in 98% of cases you will get faster application. Not only in time of execution of particular algorithms, but as a whole - load time and response time - in most cases these are that make an application to appear "fast" or "slow" for the end user. In the remaining 1% of the code you need to optimize for speed some critical algorithms that make some mass information processing.
Actually in most of the small applications there is no code that needs speed optimization.
The best way to optimize for size is to use assembly languages.
Post 14 Jun 2011, 19:28
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1412
Location: Toronto, Canada
AsmGuru62
Optimizing early is a flaw in my opinion. It is needed in cases of something very large, like big (100s Mb file parsing/searching) or big count loops or something like that. I prefer first to measure the relative speed of code (I use QueryPerformanceCounter for that) before really taking on optimization.

Also, the optimization is a balance. I was just writing a lot of code for TREK and I saw how small objects (less than 128 bytes in size) make much less code, because to access a variable at offset > 127 takes 3 more bytes than below that offset. Needless to say, that to fit a lot of information into this kind of object forced me to use bytes instead of normal INT32 values. However, access a byte from memory usually comes with penalty from CPU - DWORDs are accessed faster - especially if aligned.

I must also say, that optimizing compilers today are excellent! I use Visual Studio 2008 and compiler there is amazing - I looked at some disassembled code - it is a great code! Both in size and in speed.
Post 15 Jun 2011, 00:32
View user's profile Send private message Send e-mail Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
AsmGuru62 wrote:
I must also say, that optimizing compilers today are excellent! I use Visual Studio 2008 and compiler there is amazing - I looked at some disassembled code - it is a great code! Both in size and in speed.


I don't know how "amazing" the C++ compiler is, but strange thing - you can't create small applications in C++.
Post 15 Jun 2011, 03:13
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Enko



Joined: 03 Apr 2007
Posts: 678
Location: Mar del Plata
Enko
JohnFound wrote:
AsmGuru62 wrote:
I must also say, that optimizing compilers today are excellent! I use Visual Studio 2008 and compiler there is amazing - I looked at some disassembled code - it is a great code! Both in size and in speed.


I don't know how "amazing" the C++ compiler is, but strange thing - you can't create small applications in C++.

Yes you can, if you use your own run time library.
Wink
Post 15 Jun 2011, 03:43
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
We shifted the topic slightly. Wink HLL's are very good in "creating code" but they are very weak in "not creating code". This is IMHO the main reason for over-bloated software.
BTW, I remember one interesting project - FAIM - ICQ instant messenger by roticv.
Too bad, the project is not finished yet... it crashes sometimes. If someone want to fix it, it will be great program.
Post 15 Jun 2011, 05:51
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1412
Location: Toronto, Canada
AsmGuru62
There are some options for linker which allow to exclude RTL and set up your own entry point (instead of WinMain or main). That produces the same size EXE file as FASM. That is possible for C. C++ on the other hand has way too much riding on RTL, so it is not likely for C++.
Post 15 Jun 2011, 10:46
View user's profile Send private message Send e-mail Reply with quote
JoeCoder1



Joined: 13 Jun 2011
Posts: 62
JoeCoder1
revolution wrote:
In general: programmer time expense >>> computer time expense.

For a business intent upon maximising profit, often the sensible decision is to get it working quickly.


I have to disagree with this statement, although I wish it were true. I have seen many huge projects that went on for years and years and cost hundreds of lives and hundreds of millions of dollars. Nobody who is selling consultancy services s concerned about getting it done quickly, every hour they drag it out is money in the bank even though they are paying their subcontractors.
Post 15 Jun 2011, 11:01
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17450
Location: In your JS exploiting you and your system
revolution
JoeCoder1: "often" != "always".

There will always be exceptions, but I still believe it to be true in the general case.
Post 15 Jun 2011, 11:19
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
JohnFound wrote:
I don't know how "amazing" the C++ compiler is, but strange thing - you can't create small applications in C++.

What do you mean by "small programs"? As long as you use same things in Asm and C++, the size difference isn't that major. Of course once you start including extra libraries (STL, libc) or tables (RTTI, exception handler) in C++, code grows - but it would grow almost as much if you wanted to use these things in assembly it, it's just that in C++ everyone usually uses them and in Asm people seldom do.
Post 15 Jun 2011, 12:03
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
revolution wrote:
In general: programmer time expense >>> computer time expense.


I am also not sure, this is true. Not because the programmer expanse is low, but because it is limited in time. Once the program is created, the programming expanses decrease vastly (except for small constant support costs). On the other hand, the computer time, depends only of the count of the users and how often they use this software. I.e. if the program is rarely used it is important to be made (even quick and dirty), but with less efforts. If the program is popular and millions of people use it for long time and constantly, then the costs for computer time will raise proportionally and soon will become bigger than the efforts of creating the software.
So, it come out that the popular and most used programs (OSes, common office programs, web browsers, etc.) must be most heavily optimized in order to be economically profitable.
IMHO, the above formula is advantageous only for the software makers, and it is not true as a whole.

Also, it is obvious, that the assembly authors should concentrate themselves on common software programs that have as wide as possible user base. Internet applications, office programs, media players, etc.
Post 15 Jun 2011, 12:23
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
JoeCoder1



Joined: 13 Jun 2011
Posts: 62
JoeCoder1
revolution wrote:
JoeCoder1: "often" != "always".

There will always be exceptions, but I still believe it to be true in the general case.


I shouldn't have quoted the >> line, I was referring to what you wrote about getting a job done quickly saving money. I didn't mean to criticize you my friend, I meant to criticize the vultures of the corporate world who suck their customers dry by stretching out projects way longer than necessary. And in my experience this is virtually always. I only know of one company run by 2 guys that ever did a good job with the intention of saving their customers money and enabling them to get more customers. All the rest had dozens or hundreds of incompetent losers writing broken code and fixing it on the customer's expense.
Post 15 Jun 2011, 13:00
View user's profile Send private message Reply with quote
JoeCoder1



Joined: 13 Jun 2011
Posts: 62
JoeCoder1
AsmGuru62 wrote:
Code re-use in ASM is a big issue. If a component (or a function) can be re-used easily - then problem of developing a big project in ASM becomes kind of not that significant. Since I am working on IDE this issue is very sensitive for me. How to share code between projects? I can do it on a basis of including source code or loading DLLs and using code inside of these DLLs. Both methods have pros and cons.


Every platform/OS/assembler combination is different so there is no perfect answer without knowing exactly what you are targeting. But generally, packaging services in libraries and providing macro APIs to those services goes a long way in making code reusable and getting you a jumpstart on a new project.
Post 04 Jul 2011, 08:19
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1412
Location: Toronto, Canada
AsmGuru62
For FASM - there are only DLLs or 'include' source code. IDE will use the latter.
Post 04 Jul 2011, 11:22
View user's profile Send private message Send e-mail Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8999
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
maybe demo a live fasm only coding project during fasmcon is a good idea.
Post 04 Jul 2011, 12:16
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
yep.

it can be very instructive to see an accelerated coding session from scratch to an advanced feature like a very cool demo.
Post 04 Jul 2011, 12:20
View user's profile Send private message Visit poster's website Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
Quote:

- Bug
Read this somewhare (can't remember where) that being a low level language, asm is very bug prone. Very easy to introduce bugs.

This can be true in theory, because you have to worry about and track many more things in your assembly code logic (not so many as it was in the past, I believe, but still quite a lot).

Quote:

Actually, almost every program, written in assembly becomes better than the one written in HLL, with the same functionality. So, the quality of the assembly written software is higher than the quality of the HLL written software.

Quote:

Next reason is as most ASM programmers do not use lib, they code the whole lot, they understand the full picture, any bugs, are there bugs, so are easy to find and fix.

Very, very, very true. I could not agree more because I did not only had this impression, I have experienced it many times with my "real world" projects.

I will tell you about a recent one I have done, I decided to code it in assembly and Pascal:

High Level Language - 1st try:
First I decided to write the entire program in Pascal using its built in "Run Time Library" functions...

OK, I wrote the program, many bugs were found and fixed during the process (+a feeling of uncertainty: Is this really "secure"!? Will it really work!? Are serious bugs still present!? D:).

Assembly:
Then I started to write the same program in assembly, using only system kernel functions and my personal "Run Time Library"...

This is where the "High Level" code I wrote started to look obsolete because better and better ideas of design for the core functions of the program started to come into my mind while thinking in "assembly mode".

I applied all those "better" ideas and I finished the program, bugs were found and fixed during the developing and testing phase. Then more bugs were fixed during a deeper test phase.

It is worth mentioning about 99% of the bugs I made in the assembly code were not logic/programming errors but things I really forgot about to check for...

In "High Level Languages" the opposite is quite common, and this is bad because you are generating code out of your intended logic.

OK, I have finished the program now I will rewrite the code in the "High Level" program to implement these better ideas of design I had while thinking in assembly mode.

High Level Language - 2nd try:
My "high level" code looked so obsolete I decided to delete everything, leaving only the "command line template" intact (this is the welcome message, help menu and other options).

OK, I wrote the entire program again in "high level language" and I believe it is rock solid as far as I could test.

I believe you could throw anything at it because the logic seems to feel so simple and the implementation seems so well organized I would be impressed if there is a serious programming error in there.

Let us proceed to the testing phase again... "High Level Language" vs "Assembly" implementations:

I tested, tested, and tested and I thought - Haha, rock solid as I had thought - now let us test it with this last file... then BOOOOOM! A disappointing thing has happened. D:

A bug was met in the "high level" program and the program simply crashed outputting a file that did not look to be processed at all.

I started feeling very sad and started asking to myself: Why, why, why!? Everything looked so good, I cannot believe it.

Then I thought: let's see if the assembly variant can handle this input correctly...

Unsurprisingly, the assembly program handle it without problems, outputting a valid file.

Then I said to myself: I have been studying and practicing with this "high level language" for nothing!? I am programming in assembly for just 3 years and it gave me much less headaches.

And while the bug in the high level code is being fixed (not yet fixed)... I will give more details:

High level program size: 83kB (stripped)
Assembly program size: 6kB

Development time:
Assembly: ~12 days
High Level Language: ~2 days.

After this disappointing experience I decided: I will only use "high level language" for fast, simple, small, "out of personal standards" programs...

Which program variant I would recommend you? Pick the assembly version as I know more about its behavior. It cannot be bug free, but the chances of giving you headaches are far less. D:

In other words, assembly is my preferred programming language of choice for now. Those things about bug prone, performance problems, impossible maintenance and bla-bla-bla, from my limited experience are all myths, they were probably invented to sell compilers.

I apologize for any inconveniences I may have caused.
Post 06 Apr 2015, 05:49
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
@HaHaAnonymous, regardless of that this thread is really old, your post is very interesting, illustrating exactly what my opinion about HLL programming is. Smile
Post 06 Apr 2015, 06:23
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
gens



Joined: 18 Feb 2013
Posts: 161
gens
how big is a "Rather big project." ?
reading through some comments, my dinky 4-5k LoC project seems medium at best (serious, far from)
Post 06 Apr 2015, 12:40
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
Well, IMO, 4-5k is "medium". (Although, counting the lines of code is not very precise process).

My own projects:

BIG: Fresh IDE - 300K lines on compile / 70K lines generate some code (the remaining is macros, equations, etc). But there are files that are not used, because are parts of libraries, for the user projects.

Medium: MiniMagAsm - 38K/4.5k

IMHO, everything that is compiled should be counted, not only what you personally wrote, because this is an estimation for the project, not for programmers skills.
Post 06 Apr 2015, 12:58
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4  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-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.