flat assembler
Message board for the users of flat assembler.

Index > Heap > What is the number one goal you keep in mind when coding?

Goto page 1, 2  Next

What is the number one goal you keep in mind when coding?
size
6%
 6%  [ 3 ]
speed
4%
 4%  [ 2 ]
size/speed
33%
 33%  [ 15 ]
OS and/or processor compatibility
2%
 2%  [ 1 ]
easy to understand source code
35%
 35%  [ 16 ]
reliability/strong error checking
11%
 11%  [ 5 ]
nice UI (GUI or TUI)
2%
 2%  [ 1 ]
access/interface to something
0%
 0%  [ 0 ]
easy to configure/customize most stuff
4%
 4%  [ 2 ]
Total Votes : 45

Author
Thread Post new topic Reply to topic
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
I assume size/speed, but I wanna know what you think! Razz

P.S. I tried adding more choices, but it wouldn't let me. Surprised
Post 19 Dec 2005, 22:56
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
i voted easy to understand source because i am writing FASMLIB now. But mainly best goals are ones like FASM has - big power based on simple set of rules. Very hard to achieve.
Post 19 Dec 2005, 23:33
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
Well, it is difficult for me to choose one. I don't optimize my programs heavily, I rather try do make it easy to understand. And of course when working on Fresh I try to create nice UI Wink
Post 20 Dec 2005, 07:23
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
I wanted to choose three,
1. easy to understand source code
2. size/speed
3. easy to configure/customize most stuff

To much assembly code of today still looks like old dos code, unstructured, little or no comments (I'm guilty of this one, unfortunately), thanks to the "IF" macros of fasm, you just don't have to write code like this anymore.
Post 20 Dec 2005, 10:12
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
Actually I prefer "unstructured" code and languages where I can use "goto" constructions. This, in my opinion, allows you to actually structure your code better, with many more ways and options. Since any "structuralism" like block "if", "while", "for" can be easily emulated with simple jumps and conditions - like the classic BASIC's "IF condition THEN GOTO line"; and some other like "try"-"catch" were actually designed to provide something you've got for free when using jumps. And constructions like "return" and "break" in "structured" languages also break the regular program flow and sometimes may cause even more confusion than well-designed and described (at least by meaningful labels) "jump cascades". (If they ever asked me, I would vote for including "goto" in PHP, hehe).

So... you see now why example programs written by me never use the ".if" macros.

As for not adding comments, I'm VERY guilty of this one, but... well, every time I tried to add comments to fasm's source I ended up actually coding anyway. Wink
Post 20 Dec 2005, 10:40
View user's profile Send private message Visit poster's website Reply with quote
Octavio



Joined: 21 Jun 2003
Posts: 366
Location: Spain
Octavio
..


Last edited by Octavio on 20 Dec 2005, 12:41; edited 1 time in total
Post 20 Dec 2005, 12:34
View user's profile Send private message Visit poster's website Reply with quote
Octavio



Joined: 21 Jun 2003
Posts: 366
Location: Spain
Octavio
rugxulo wrote:
I assume size/speed, but I wanna know what you think! Razz

P.S. I tried adding more choices, but it wouldn't let me. Surprised

It depends on what i´m coding , for boot sectors i optimize just for size
for libraries i also optimize speed,for filesystem code i optimize for reliability ,and sometimes i don´t optimize at all to save coding time.
Post 20 Dec 2005, 12:40
View user's profile Send private message Visit poster's website Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
decard wrote:
.... I rather try do make it easy to understand. ...

Thank you! Much appreciated.
Readability is the key to modification of ANY program, in ANY language. Speed is utterly irrelevant, not only because the cpu's today are 1-100 THOUSAND times faster than the fastest cpu's of the 1970's, [when the authors of "standard" textbooks (advocating SPEED improvements in writing software) were gaining their own educations,] but also because IF ONE REALLY needs VERY fast computations, the Intel architecture is certainly not the proper solution.
EASY TO UNDERSTAND--definitely the right choice!
Smile
Post 20 Dec 2005, 19:55
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
tom tobias wrote:
IF ONE REALLY needs VERY fast computations, the Intel architecture is certainly not the proper solution.

Well, this is not the point in this discussion, but I heard the PCs are thought to have the cheapest computing power available currently (check out the computer clusters).
Post 20 Dec 2005, 20:15
View user's profile Send private message Visit poster's website Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
Tomasz Grysztar wrote:
...I heard the PCs are thought to have the cheapest computing power available currently (check out the computer clusters).

It has been true since the late 1970's when many desktop computers made their first appearance. Price performance curves since then have consistently shown the benefits of such machines compared with "main frames" or "minicomputers".
http://www.ddj.com/
One can compare performances on benchmarks, such as the execution time for a small dimension FFT, for example 256 points, in the issue from mid 1990's, compared with a VAX architecture, costing approximately ten times as much, but computing the transform (hand written in assembly language, not compiler generated code on both desktop--Intel-- and VAX) only about twice as fast on the VAX.
However, as you pointed out, yes, your comment was slightly off topic, though a very interesting diversion, much appreciated. Glad to read that you have time for such thoughtful replies..... Cool
Post 20 Dec 2005, 20:29
View user's profile Send private message Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1171
Location: Overflow
Matrix
hi,
it depends on what i want to do,

but i think if possible all options are good.
Post 20 Dec 2005, 21:24
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Well, some projects (e.g., MAME) seem to do "accuracy" first and then "OS portability" second and "as many game architectures emulated as possible" third. They claim Pac-Man and Donkey Kong would run on such an "old" machine as a P166, but I very much doubt it. Size and speed ain't a concern for them. You'll need 1Ghz and 128/256 MB RAM to run half of the stuff MAME supports.
Post 21 Dec 2005, 00:44
View user's profile Send private message Visit poster's website Reply with quote
Ivan2k2



Joined: 08 Sep 2004
Posts: 80
Location: Russia, Angarsk
Ivan2k2
my 1st choice is "reliability/strong error checking", most time i use for debugging...
my 2nd shoice is "size/speed" optimization, and after optimization again debugging
Post 21 Dec 2005, 14:00
View user's profile Send private message ICQ Number Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
Quote:
Actually I prefer "unstructured" code and languages where I can use "goto" constructions. This, in my opinion, allows you to actually structure your code better, with many more ways and options. Since any "structuralism" like block "if", "while", "for" can be easily emulated with simple jumps and conditions - like the classic BASIC's "IF condition THEN GOTO line"; and some other like "try"-"catch" were actually designed to provide something you've got for free when using jumps. And constructions like "return" and "break" in "structured" languages also break the regular program flow and sometimes may cause even more confusion than well-designed and described (at least by meaningful labels) "jump cascades". (If they ever asked me, I would vote for including "goto" in PHP, hehe).

So... you see now why example programs written by me never use the ".if" macros.


Tomasz: There are times when unstructured goto code is the better choice, but this is rare, especially when writing windows code. I use the macros mainly because they make the code easier to read (to me anyways), and because using them has no noticable speed loss when using direct 'jcc' and jmp instructions. The main reason I dislike direct 'jcc' jumps is because it can easily get out of control, and then when you want to go back and make a modification or addition, you have to try and untangle the mess that you created. Managed code has the opposite problem, too much indirection for about every windows function and variable, but that's a whole other forum topic! Very Happy
Post 21 Dec 2005, 20:23
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
madmatt: you can get unstructured code "under control", but it takes some practice (just like it took some practice to get structured code "under control"). And then you will hate to use structured code, it will limit you, because your algorithmic thinking will have wider range than structured code provides you.
Post 21 Dec 2005, 22:54
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
vid: I've programmed unstructured code a long time (years 1982 - 2000). I was resisting using the fasmw macros because for so long I was used to the old ways (unstructured basic and asm coding), but when I started to use them, they made programming a lot easier by eliminating a lot of the label hell i was having. Indenting will help top down assembly code by defining where loops start and end, but the 'IF' macros just look much better to me. By the way, My "algorithm flow" hasn't suffered at all by using the fasmw macros, quite the opposite. Smile
Post 22 Dec 2005, 00:34
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
Well, I realize that my opinion in this topic is contrary to what the majority of programmers (and even worse: IT theoreticians) think/say. Nonetheless I hope there are some people able to see my point. Wink
Post 22 Dec 2005, 07:30
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
madmatt:
Code:
;searching in 2D array pure HLL style, where you need to get out of 2 loops
item=0;
for (y=0, (item!=searchkey) &&(y<n), y++)
  line=getline();
  for (x=0,  (item!=searchkey) &&(x<n), x++)
    item=getitem();
    if (item != searchkey)
      move_to_next_item(line);
    endif
  endwhile
  if (item != searchkey)
    move_to_next_line();
  endif
endwhile    

vs.
Code:
  ;for every line
  mov edx,[n] ;line number
.line_loop:
  invoke getline, edx
  mov ebx, eax ;line object

  mov ecx,[n] ;item number
.item_loop:
    invoke getitem, ebx
    cmp eax, [searchkey]
    je .item_found
    invoke move_to_next_item, ebx
    loop .item_loop

  invoke move_to_next_line
  dec edx
  jz .line_loop    
Post 22 Dec 2005, 11:36
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Frank



Joined: 17 Jun 2003
Posts: 100
Frank
Number One goal: to make everyone involved happy -- (a) the programmer, (b) the processor, and (c) the user. In that order.

Point (a) means to write pure assembly code, with lots of comments, but with only very few macros. The reason is that if I return to the code in six months time, I will have to look up how, exactly, a certain macro works, and what its side-effects are. But I will always understand immediately what JNZ @B does.

Point (b) means to deviate from the techniques that most assembly boards teach (e.g., parameter passing through memory, EBP-consuming stack frame for local variables). Instead, do things the "proper" assembly way (pass parameters in registers, use EBP as a general-purpose register).

Point (c) automatically falls out of the process, because (a) and (b) together result in small and fast programs Very Happy

Regards

Frank

Code:
; ------------------------------------------------------------------------------
; Wrapper for the API-function ReadFile
;
; Input:        - EAX = hSource:   handle of source to read from (file, console, ...)
;               - EDX = lpBuffer:  address of buffer receiving the data
;               - ECX = nMaxBytes: max. number of bytes to read
;
; Return:       - EAX:          number of bytes read, or -1 on failure
;
; Interna:      According to the Platform SDK (February 2003), ReadFile sets the
;               number-of-bytes-read variable to zero anyway. Hence we do not
;               need to initialize it ourselves.
;

fastcall read, hSource,lpBuffer,nMaxBytes

        push    ebx

        push    ebx                     ; create space for a DWORD on the stack
        mov     ebx,    esp             ; EBX = address of stack-variable
        stdcall ReadFile, eax,edx,ecx,ebx,0
        cmp     eax,    1               ; set carry-flag if ReadFile returns 0 ( = error)
        pop     eax                     ; EAX = number of bytes read
        sbb     edx,    edx             ; EDX = -1 if error, 0 otherwise
        or      eax,    edx             ; EAX = -1 if error, unchanged otherwise

        pop     ebx

        ret

endp
    
Post 22 Dec 2005, 16:45
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
frank: nice said, but i wouldn't call "fastcall" convention "fast" or "asm-proper" in any meaning. I would rather use any of EBX, EDX, ESI, EDI for argument than ECX. Using ECX and EDX comes from real-mode 16bit instructions, where these two couldn't have been used as address. But ECX is often used for REP, so you have to store it somewhere anyway. There was discussion about this somewhere.

btw, passing arguments in register often leads to confusion, and sometimes isn't faster anyway. And it has lower readability than through stack (suhc arguments are named in source, unlike registers where you don't always remember which register holds which arg)
Post 22 Dec 2005, 18:04
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number 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-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.