flat assembler
Message board for the users of flat assembler.

Index > Main > What is your favourite calling standard?

Goto page Previous  1, 2, 3
Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
bitRAKE wrote:
to use [ebp as a stack frame pointer] generally in that manner is to instantly code at a lower performance level than compiled HLL code.
How do you come to that conclusion? The worst you could expect is to at least match the HLL code. Notice that the calling standard I posted does not dictate how to access the stack frame inside the functions, this was a deliberate omission.
Post 01 Mar 2008, 09:40
View user's profile Send private message Visit poster's website Reply with quote
ic2



Joined: 19 Jan 2008
Posts: 75
ic2
I thought you had posted a link to the latest version of Olly but it was LocoDelAssembly. Doing my short time flying though the site reading everything possible, you and he seems to have the same style.

Anyway, Thanks revolution, 1st lesson learned. There's too many important things to learn about Fasm so I will not be wasting time anti-debugging for quite a while. Back to the manual for me.

DEAL ...
Post 01 Mar 2008, 16:39
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2913
Location: [RSP+8*5]
bitRAKE
To talk of the external appearance of the interface without how that will be implemented is kind of one-sided. Which really is the whole problem with standards: code itself dictates a minimal interface which is specific to the routine, but standards seek a minimal description of all interfaces.

Sure algorithms can be implemented for any calling convention, but rarely is that the minimal interface needed by the algorithm. So, the question, "What is gained by a standard calling convention?" If we can instantly see what the interface is and know x86 sufficiently - nothing.

_________________
¯\(°_o)/¯ unlicense.org
Post 01 Mar 2008, 16:47
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
bitRAKE wrote:
To talk of the external appearance of the interface without how that will be implemented is kind of one-sided. Which really is the whole problem with standards: code itself dictates a minimal interface which is specific to the routine, but standards seek a minimal description of all interfaces.
Hmm, can't agree there, code dictates nothing really. At the most I will grant you that the instruction and register sets will have an influence upon the interface that is appropriate.
bitRAKE wrote:
Sure algorithms can be implemented for any calling convention, but rarely is that the minimal interface needed by the algorithm. So, the question, "What is gained by a standard calling convention?" If we can instantly see what the interface is and know x86 sufficiently - nothing.
They gain you a lot of determinism between functions. Without having to continually check what each and every function requires and returns the confidence is increased and debugging is reduced. The gain must be weighed against the cost. If performance of a particular routine is severely* curtailed by forcing it into a particular calling standard then you may be justified to select a different method. But this should ideally be done with great care to make sure it is necessary. Willy-nilly changing of calling standards within a single app can create more problems than it solves, so it pays to make sure one is 100% sure it will prove beneficial before doing it.

* The measurement parameter of severe is, of course, indeterminate and varies for each app. An app that must perform at peak performance over a long period (eg. Prime95) will have a very narrow definitions of severe and acceptable. An app with brief periods of computation and long periods of idle (eg. Acrobat reader) will have very wide definitions of severe and acceptable.
Post 01 Mar 2008, 16:56
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2913
Location: [RSP+8*5]
bitRAKE
Ah, so you primarily code to the interfaces.

Sorry, never could do that.

_________________
¯\(°_o)/¯ unlicense.org
Post 01 Mar 2008, 17:33
View user's profile Send private message Visit poster's website Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
daniel.lewis
Razz Yeah, I don't

Quote:
Willy-nilly changing of calling standards within a single app can create more problems than it solves


Can you provide an example? I haven't seen such a case yet.

As for obfuscating your code, I think it's a shameful activity. We should be trying to *help* people understand the truth, not trying to blind them to it.

If your product is just one of 64 products that do the same thing, nobody cares enough to reverse your shit. If it's truly amazing software, an open source version will be made if the guys think it's harder to reverse than rewrite. That'll be more damaging, because the open source version will be accepted by even those people who have moral stipulations with cracked software.

Proprietary software exists in four forms in my world:

1) the obscure, rarely used stuff
2) stuff huge corps use, like at my work
3) stuff that's cutting edge, and pulling some cash before it's open sourced.
4) windows.

_________________
dd 0x90909090 ; problem solved.
Post 02 Mar 2008, 06:37
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
daniel.lewis wrote:
Quote:
Willy-nilly changing of calling standards within a single app can create more problems than it solves
Can you provide an example? I haven't seen such a case yet.
As you write more and more code you will come to realise some things. The hardest part is to be able to recognise that there is a problem. Most new programmers don't understand that what they are doing is creating problems because they have no experience with a coding style that does not create those problems. They merrily solve all the little problems one-by-one, and the result works for them. But they do all of this without even understanding that other methods may have avoided those little niggling problems before they happened.

It is easy to say that a particular coding method is not problematic, but without having a good amount of experience with other coding methods that conclusion is suspect at best.
Post 02 Mar 2008, 06:50
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2913
Location: [RSP+8*5]
bitRAKE
So, now the claim is that there is some special experience that makes future experience less valuable. This is not the case. Children today make the same mistakes children have been making for thousands of years - parents are doing it too. Wink

The experience itself gives value to the abstractions. To give people abstractions and say, "value these" - doesn't work.

_________________
¯\(°_o)/¯ unlicense.org


Last edited by bitRAKE on 03 Mar 2008, 01:45; edited 1 time in total
Post 02 Mar 2008, 19:58
View user's profile Send private message Visit poster's website Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
daniel.lewis
@Revolution:

While you weren't far off with mentioning ESP as being a GPR, in practice it's not safe to do so simply because certainly nameless operating systems tend to check it to make sure it's inside the stack to prevent buffer overflows.

Quote:
As you write more and more code you will come to realise some things.

Yeah, I've been coding for 12 years when I started writing SGML in 1997. I work as a scripter for the largest company in the world. My aunt has a fellowship in IBM, my mother worked on mainframes in RPG40, and my first PC had nothing but a 5 1/4" floppy drive. Engineering, architecture, math, and recently computer science has been in the family for over 300 years.

Quote:
The hardest part is to be able to recognise that there is a problem. Most new programmers don't understand that what they are doing is creating problems because they have no experience with a coding style that does not create those problems.

I don't see a problem, but then that must be the problem? Woe is me. Just because a methodology confuses you, doesn't mean it's problematic to the rest of the world. I actually revel in it.

Quote:
But they do all of this without even understanding that other methods may have avoided those little niggling problems before they happened.

Could you perhaps be a little more ambiguous? I'm well aware of __cdecl, stdcall, fastcall, pascal etc. etc. I understand them. I could write a cute little book on them but I'm not in the department of redundancy department.

Quote:

Quote:

Willy-nilly changing of calling standards within a single app can create more problems than it solves

Can you provide an example? I haven't seen such a case yet.


Take the pepsi challenge.

Your use of language, revolution, thusfar definitely isn't causing me to gain respect for you or what you have to say. I also find your efforts to insult my intelligence transparent and base, which would be much more tolerable if you could fork out the evidence. I don't mind being told I'm wrong, as long as I'm told why.

You very well may have a good example, but you're evidently failing to make your point. I'm hoping you will. For the last few months, I've been longing for a change in paradigms.

_________________
dd 0x90909090 ; problem solved.
Post 03 Mar 2008, 00:29
View user's profile Send private message Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22
re: daniel
Please don't insult us with logical fallacies.

1) Your family history is irrelevant and trying to pass it off as personal experience is laughable.

2) The number of years you've been programming is meaningless. Now referring us to a project you've worked on would be a much better way of touting your experience. There are plenty of programmers that have been in the industry for decades and still write crap/spaghetti code, but those programmers are almost NEVER attached to any significant projects.

3) Saying you work for the largest company in the world as a scripter has zero relevance on your ability to write good assembly.

3.5) The irony of you calling Revolution out on being "ambiguous", while defending your "confuses you"/ambiguous calling convention did not escape me, and I got a chuckle out of it.
---------------------------------------

On Topic:

If you want to say using a non standard calling convention makes your programs faster/better in any way then you need to back it up.
Now if you use it "just because" thats fine too, just don't expect anyone to bother with your source code.

When speed is a concern there's only 4 things you need to do:
- Optimize the underlying ALGORITHMs
- Inline your functions
- Unroll loops
- Parallelize (SIMD) and multi-thread

Inlining negates the need for any calling convention mangling.

In most cases, I prefer to use a familiar standard; preferring the one used by the OS that I'm developing for.
Post 04 Mar 2008, 00:05
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
daniel.lewis
Off Topic:

1) My family history isn't irrelevant. I was learning things like binary sort at 11 because my aunt explained it to me. Much of what I do is relevant to my having gained sufficient experience.

2) You're right. I could spend years being an assembler programmer and not even be comfortable leaving __cdecl calling convention, or Java Programmer and walk away not even knowing what the "<<" operator does. I'm capable of innovative, creative thought though.

3) Agreed, but the fact that I do does have relevance to my being able to program maintainable, well documented code; my having exposure to other people's source, and my source being reviewed regularly by both programmers and managers alike.

3.5)
Flexibility in a calling convention is a "feature". I believe there was someone else who said exactly that in one of the above posts with regards to stack usage.

Ambiguously saying
Quote:

Willy-nilly changing of calling standards within a single app can create more problems than it solves

doesn't make any point. His entire post, in context, is roughly equivalent to saying:

"I don't like that. You are poopoo."

THAT is the difference. I was asking him to provide some measure of evidence to back up his claim. Not the poopoo one. The one that it creates more problems than it solves. Something which is ON TOPIC, unlike your request for my resume.




On Topic:

revolution went into calling down my intelligence and experience, but you guys still can't face the issue at hand. What makes:

Code:
push x
push y
push z
call a

a:
 push ebp
 mov ebp, esp

 bla bla bla ginger

 pop esp
 pop z
 pop y
 pop z
 ret
    


so much more maintainable that you feel the need to focus on insulting me when I suggest using something leaner and more appropriate? From the on-topic comments I've seen so far, it's simply because you're incapable of reading comments?

Straight from my own snippets:

Code:
; String_indexOf
;     Synopsis:
;       return index of start of needle in haystack
;       flag ne means no match
;
;     Registers:
;       ESI = haystack  
;       EDI = needle
;       ECX = haystack.length
;       EDX = needle.length
;       taints XMM0,XMM1,XMM2,XMM3

String_indexOf:
     ...
    


Is that so unfathomably difficult? Laughing

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



Joined: 21 Jul 2003
Posts: 2913
Location: [RSP+8*5]
bitRAKE
It might even be arguable that the assumptions of a 'standard' calling convention lead to more delays due to errors than the time saved in assuming. Personally, I've replied to dozens of posts (across the i-hwy) regarding the epilogue/prologue for functions/proceedures. Hope I haven't lead too many astray, lol.

_________________
¯\(°_o)/¯ unlicense.org
Post 05 Mar 2008, 02:51
View user's profile Send private message Visit poster's website Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
daniel.lewis
daniel.lewis wrote:
Is that so unfathomably difficult? Laughing


Heh... apparently. I forget to mention in my comments that I return the result in EAX. Confused

_________________
dd 0x90909090 ; problem solved.
Post 05 Mar 2008, 04:06
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7721
Location: Kraków, Poland
Tomasz Grysztar
daniel.lewis wrote:
Code:
push x
push y
push z
call a

a:
 push ebp
 mov ebp, esp

 bla bla bla ginger

 pop esp
 pop z
 pop y
 pop z
 ret
    

It's a bit strange thing you put here instead of LEAVE + RETN 12. Unless the "bla bla bla" does some stack shuffling, it won't work.

daniel.lewis wrote:
Straight from my own snippets:

Code:
; String_indexOf
;     Synopsis:
;       return index of start of needle in haystack
;       flag ne means no match
;
;     Registers:
;       ESI = haystack  
;       EDI = needle
;       ECX = haystack.length
;       EDX = needle.length
;       taints XMM0,XMM1,XMM2,XMM3

String_indexOf:
     ...
    

Yeah, that's the same kind of convention I use (I only I can - that is when I don't have to make the procs callable from some other language) and for the pure assembly code I consider it the best.
Except I sometimes even don't put the comments there (see fasm sources) Wink
Post 05 Mar 2008, 06:42
View user's profile Send private message Visit poster's website Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
daniel.lewis
Heh, yeah, I really bungled that one up. I'm pushing before the call, and popping before the ret.

*sigh* must.. sleep.. more.. often. :p
Post 05 Mar 2008, 07:43
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2913
Location: [RSP+8*5]
bitRAKE
Windows system call interface is interesting. Basically,
Code:
.A:  xor eax,eax
     lodsb
     pop edx
     sysenter    
...is all that is needed. Assuming ESI is a list of function numbers, and the top of stack points to the list of parameters. Because windows ignores (doesn't write to) [ESP] a chain of function parameters can be used somthing like:
Code:
mov esi,scab
     call .A

     dd .B ;-> EIP
     dd .1 ; top of stack on return
     dd SystemPerformanceInformation
     dd spi
     dd spi.sizeof
     dd 0
.1:  dd .C
     dd .2
     dd -1
     dd pAddr
     dd 0
     dd pBytes
     dd MEM_COMMIT
     dd PAGE_EXECUTE_READWRITE
.2: ...

.B:  imul ecx,[spi.AvailablePages],4096
     mov [pBytes],ecx
     jmp .A
.C: ...

scab db NtQuerySystemInformation,NtAllocateVirtualMemory,...    
Kind of silly for windows to be doubling all the parameters on the stack - damn near every API does that - some tripple/quadruple just adding another constant.

_________________
¯\(°_o)/¯ unlicense.org
Post 05 Mar 2008, 11:55
View user's profile Send private message Visit poster's website Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
daniel.lewis
Yeah, Lua and most JavaScript engines make every function include a pointer to the "scope/context". This solves the problem of Global being a constant which prevents you from having more than one running at the same time, but it's just *wrong*

I had thought to simply use [ESP+36] or whatever the case may be to get it from the caller directly, but then that would be dependent on stack depth and painful to calculate through recursion.

So now it's dynamically allocated, and I've opted to use ring-queueing to handle active and dormant engine States.

Best Regards,
Dan
Post 06 Mar 2008, 07:05
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.

Powered by rwasa.