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.




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






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

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.

Opps, I guess I was a bit harsh

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

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

you forgot the code tags...

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



in risc, it gives:

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

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.

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.



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

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