flat assembler
Message board for the users of flat assembler.

Index > Main > How fast is it really?

Goto page Previous  1, 2, 3
Author
Thread Post new topic Reply to topic
CBB



Joined: 28 Feb 2008
Posts: 7
CBB
Code:
    


Last edited by CBB on 31 Mar 2008, 22:10; edited 1 time in total
Post 31 Mar 2008, 18:44
View user's profile Send private message Reply with quote
CBB



Joined: 28 Feb 2008
Posts: 7
CBB
Code:
    


Last edited by CBB on 31 Mar 2008, 22:11; edited 1 time in total
Post 31 Mar 2008, 19:20
View user's profile Send private message Reply with quote
MichaelH



Joined: 03 May 2005
Posts: 402
MichaelH
CBB wrote:

Well, gas is also written in C, and I'd argue it's doing rather fine


Hmmm .... I guess if you're going to screw my test results to believe C can compete with assembler I suppose you're right.

I'll give you the benefit of the doubt about processor speed and multiply my result by 2 to compensate.

2 * 0.02739734 = approx 0.055

That still kicks your gas test even though there are more lines of code and more symbols (1700)

However I don't believe a budget AMD Sempron 3100+ (1.8ghz) low end processor will be too much faster than a high end Athlon 1GHz. Ram size is only important if while assembling you run out of it, 256MB RAM is far more than what is needed.


CBB wrote:

WAIT A MOMENT... Your numbers are for building the entire program? Do you use the builtin linker?!


Builtin linker? Sorry, I can't figure out hll nonsense talk.


Here is the result of casm using it's execute command of the assembled code. The code is written to disk and then executed but eventually I will create the process within casm which should mean the code should run not to soon after the end figure.

Note the last figure has a different processID


Code:
0.00000000    [1632] casm
0.00023355       [1632] initialise
0.00045928 [1632] preprocessor
0.00062466       [1632] parser
0.00074479     [1632] assembler
0.00091827  [1632] formatter
0.00387675  [1632] end 
0.01494212       [1648] formatMessage test <-- this is slow, need to create process instead of writing to disk then executing.
    


CBB wrote:

What are your numbers for creating object files without linking?


Object files? Sorry, I just can't follow hll gobbly gook. It's like trying to read a foreign language.

Good luck with your nonsense C .... you know what I think would be good for you ...... Smile
Post 31 Mar 2008, 20:48
View user's profile Send private message Reply with quote
Octavio



Joined: 21 Jun 2003
Posts: 366
Location: Spain
Octavio
CBB wrote:
WAIT A MOMENT... Your numbers are for building the entire program? Do you use the builtin linker?!

Fasm takes the same time to generate a obj file than a executable
The times posted by Michaelh are not accumulative,the last number is the total time.
Post 31 Mar 2008, 21:28
View user's profile Send private message Visit poster's website Reply with quote
MichaelH



Joined: 03 May 2005
Posts: 402
MichaelH
Opps, I guess I was a bit harsh Sad

CBB, if you're still out there I'm sorry. Yes it's a bit of a shock for a C\C++ programmer to realise just how much faster assembler is.

Good luck to you

Regards Michael
Post 31 Mar 2008, 22:46
View user's profile Send private message Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
daniel.lewis
Rather than being harsh, it's good to provide a real argument. Rather than affecting their egos, it causes people to re-examine their choices from the logos; which is the more effective approach when you want others to expand their awareness of things.

To back you up;

C, and other programming languages, were created essentially to compensate for a difficulty understanding large volumes of assembler and/or machine code. To that end, it's somewhat successful. I can examine roughly 120 lines of assembler code in only 20 lines of C. However, there are some major drawbacks to the approach.

C has issues in the api; for example strlen, fprintf, malloc, etc. that are absolutely atrocious. To back that, strlen shouldn't exist as a function because it's much faster to simply store the length as a datum. fprintf, fputs, puts, printf etc. are all inconsistent with a great deal of bloat and corner cases. malloc can never guarantee a return but you still have to check for null in case it does, and it's SLOW. Unfortunately, the bad api is the standard api so there's little progress.

C has issues in the flow control provided; for example try to write this modified duff's device in C, and flow control needs be reduced to goto statements.

mov EBX, ; table? (I can't remember the details of xlatb)
mov EAX, ; 0?
jmp cNext
align 4
c0x0A:
cmp byte [ESI+1], 0x0D
sete DL
add ESI, EDX
align 4
c0x0D:
inc [line]
align 4
cNext:
inc ESI
lodsb
xlatb; this table is used to calculate offsets, including cNext, c0x0D, and c0x0A.
...
jmp EAX
I would argue that such is more the rule than the exception; that most loops and functions in C are "stuffed" into the C expected shape from their natural form. The result of this is always a degradation in the elegance of the algorithm.

The simple fact is that assembler is orthagonal to machine code; and as such it can accomplish exactly what the machine can. Any other language will be a subset of assembler's capabilities; because it must be able to exist as machine code and hence as assembler in order to run.

Likewise, because assembler is orthagonal all other languages, where they provide features beyond that which identity maps to machine code, only produce clutter where those features are not used.

These are the central reasons why C, and every other programming language, will always take a back seat to assembler.

To adjust for the human readability of C, I would propose developing an open source project which provides a flow control graphing mechanism similar to IDA Pro. The later introduction of drag and drop functionality and complete-system integrated possible-value-domain register analysis would allow developers to avoid a vast set of bugs and provide detailed and immediately relevant information as we code.

Best Regards,
Daniel

_________________
dd 0x90909090 ; problem solved.
Post 31 Mar 2008, 23:47
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4237
Location: 2018
edfed
you forgot the code tags...

xlat is simple
ebx is the base pointer for the table and al is the offset in the table.

Code:
...
mov ebx,table
mov al,char
xlat
...
table:
db 0,0,0,0,1,1,1,1,2,2,2,3,3,45,64,56,4,46,44,4,12,12,12,12,5,45,4,45,4,4,5,24,86,98,7,7,78,9,98,45,64,64,5,61,31,3,46,54,64,7,47,89,9,8,65,45,64,32,12,31,32,13,1,23,53,46,54,56,56,46,77,89,7,45,6,46,123,132,132,1,3,21,65,4,6,54,98,7,46,45,6,4,56,123,1,3
times 256-($-table) db 0
    


in risc, it gives:
Code:
mov ebx,table
mov eax,char
mov al,[eax+ebx]
    
Post 01 Apr 2008, 00:36
View user's profile Send private message Visit poster's website Reply with quote
MichaelH



Joined: 03 May 2005
Posts: 402
MichaelH
Thanks for the support daniel but the idea was as you state, to get CBB to look deeper and question his beliefs about what he was trying to achieve, not to scare him away all together. So unfortunately I failed Sad

Maybe all may not be lost. Hopefully others will read this thread and will abandon programming fasm macro language and start learning assembler. This is the only reason people addicted to HLL programming beleive languages like c\c++ actually compete with assembler.
Post 01 Apr 2008, 04:18
View user's profile Send private message Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
daniel.lewis
Michael, one person possibly leaving because of a mild rant on his use of C and compiler tools isn't something worth flogging yourself with. Just be more careful to rant about the right things.

Quote:
I'm intentionally trying to be piss off people who say stupid things hoping that people that disagree will either leave or respond with something substantively different that I can learn from


- myself, shortly before a flame war erupted on this very forum that resulted in people reducing themselves to namecalling for their inability to provide intelligent refutation.

I guess you can't win 'em all.

Rolling Eyes Edfed, I shall endeavor to make sufficient use of the code indicators from this day forward. Any arguments for or against my main points?

_________________
dd 0x90909090 ; problem solved.
Post 01 Apr 2008, 05:04
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3

< 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 cannot 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.