flat assembler
Message board for the users of flat assembler.

Index > Heap > Aspect Oriented Programming and Assembly Language

Author
Thread Post new topic Reply to topic
kalambong



Joined: 08 Nov 2008
Posts: 165
kalambong
Someone told me of "Aspect Oriented Programming" thingy just the other day - looks like it's a "programming paradigm", according to wikipedia http://en.wikipedia.org/wiki/Aspect-oriented_programming

My question to you guys is - can this "AOP" method be applied to assembly language?

edit by revolution: fixed url
Post 11 Jan 2012, 04:20
View user's profile Send private message Reply with quote
kalambong



Joined: 08 Nov 2008
Posts: 165
kalambong
I searched online for info regarding AOP and Assembly Language, got no encouraging result.

But apparently one other guy was looking for similar thing.

URL is http://stackoverflow.com/questions/2210669/what-aop-tools-exist-for-doing-aspect-oriented-programming-at-the-assembly-langu

And let me quote that guy:

"I have already done object-oriented AOP. I know assembly language for x86 and so forth. I would like to be able to do logging and other sorts of things using the familiar before/after/around constructs.

I would like to be able to specify certain instructions or sequences/patterns of consecutive instructions as what to do a pointcut on since assembly/machine language is not exactly the most semantically rich computer language on the planet.

If debugger and linker symbols are available, naturally, I would like to be able to use them to identify subroutines' entry points , branch/call/jump target addresses, symbolic data addresses, etc.

I would like the ability to send notifications out to other diagnostic tools. Thus, support for sending data through connection-oriented sockets and datagrams is highly desirable. So is normal logging to files, UI, etc.

This can be done using the action part of an aspect to make a function call, but then there are portability issues so the tool needs to support a flexible, well-abstracted logging/notifying mechanism with a clean, simple yet flexible.

The goal is rapid-QA. The idea is to be able to share aspect source code braodly within communties as well as publicly. So, there needs to be a declarative security policy file that users can share. This insures that nothing untoward that is hidden directly or indirectly in an aspect source file slips by the execution manager.

The policy file format needs to be simple to read, write, modify, understand, type-in, edit, and generate. Sort of like Java .policy files. Think the exact opposite of anything resembling XML Schema files and you get the idea."
Post 11 Jan 2012, 09:19
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1409
Location: Toronto, Canada
AsmGuru62
It sounds like a bunch of non-sense -- that article.
Post 11 Jan 2012, 15:10
View user's profile Send private message Send e-mail Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
I've heard someone once telling that this is just Decorator pattern and I don't remember what other thing in disguise.
Post 11 Jan 2012, 15:21
View user's profile Send private message Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2913
Location: 0x77760000
typedef
I still don't get why people try to implement High Level Language attributes in Assembly when in Assembly you can do whatever you want , without boundaries.

Maybe that's what makes newbies not want to learn Assembly
Post 11 Jan 2012, 18:59
View user's profile Send private message Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 619
cod3b453
Aspect orientated programming deals with "cross cutting concerns". In a large system, you have discrete groups of files that are loosely coupled and highly coherent (this can also be any other paradigm) but in certain cases (such as logging) the same functionality must be shared across these discrete files, which normally means changing all of these files to implement non-critical functionality.

In the case of tools like AspectJ (for Java), you can capture defined patterns of execution e.g. before/after/around initialisation/call <pattern> and even include the current call stack cflow/cflowbelow. So I could define a rule that says "after a call to a class with method called toString() and the current call stack contains a previous call to toString() : write a log message". This modifies the compiled output to perform these actions, some can be compiled directly in others have to be captured at run time; both impact performance but reduce code modification overheads.

There's no reason why this cannot be achieved with macros, and in fact some macros could be considered aspects, where they perform instruction replacement or note their relative locations in code to perform specific actions.
Post 11 Jan 2012, 19:31
View user's profile Send private message Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2913
Location: 0x77760000
typedef
But what is it needed for ?

For example, right now I'm working on a System file editor. So what can Aspect Oriented Programming do ? Will it make any difference if I implement it ? Will it bloat my program or not ?
Post 11 Jan 2012, 20:07
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
The problem with all these paradigms, is that they are mostly created to limit the programmers freedom. Assembly on the other hand gives all control in the hands of the programmer and thus it contradicts with every HLL concept - OOP, AOP etc.
Nevertheless, some of these concepts can be used with assembly language, but the implementation consists mostly of the programming style, than the programming syntax.
Post 12 Jan 2012, 07:19
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1409
Location: Toronto, Canada
AsmGuru62
OOP in its minimal set is very effective in reducing development time for a project. Especially, large project. But the attempts to OOP in ASM have been unsuccesful so far. We'll see what happens with my approach.
Post 12 Jan 2012, 11:29
View user's profile Send private message Send e-mail Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2913
Location: 0x77760000
typedef
Flat Assembler, remember guys
Post 12 Jan 2012, 15:48
View user's profile Send private message Reply with quote
kalambong



Joined: 08 Nov 2008
Posts: 165
kalambong
cod3b453 wrote:
Aspect orientated programming deals with "cross cutting concerns". In a large system, you have discrete groups of files that are loosely coupled and highly coherent (this can also be any other paradigm) but in certain cases (such as logging) the same functionality must be shared across these discrete files, which normally means changing all of these files to implement non-critical functionality.

In the case of tools like AspectJ (for Java), you can capture defined patterns of execution e.g. before/after/around initialisation/call <pattern> and even include the current call stack cflow/cflowbelow. So I could define a rule that says "after a call to a class with method called toString() and the current call stack contains a previous call to toString() : write a log message". This modifies the compiled output to perform these actions, some can be compiled directly in others have to be captured at run time; both impact performance but reduce code modification overheads.

There's no reason why this cannot be achieved with macros, and in fact some macros could be considered aspects, where they perform instruction replacement or note their relative locations in code to perform specific actions.



Yes, I do see the similarity between macros and aspects, that was why I started this thread to begin with

The thing with me is I am not smart enough ~ in fact, I got a very very dull brain ~ to figure out a way to adopt the gist of AOP into ASM.
Post 13 Jan 2012, 04:04
View user's profile Send private message Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 619
cod3b453
Here's something I just made up that allows logging (in this case breakpoints on) a certain call and the ability to replace an existing procedure with a new one -- in both cases these can be defined in external headers for different builds and behaviors.
Code:
        use32

; Override the call instruction
macro call id
{
 common

 ; Verbose logging
 if defined __log_#id
        display 'Logging ',`id,' called here',0x0D,0xA

        nop
        int3 ; some logging code here
        nop
 end if

 ; Verbose rerouting
 if defined __reroute_#id
        display 'Rerouting call to ',`id,0x0D,0xA
        call __reroute_#id
 else
        call id
 end if
}

; Allow call logging
macro @log_call_to id
{
        __log_#id = 1
}

; Allow call rerouting
macro @reroute_call_to id,newid
{
        __reroute_#id = newid
}

        ; Define behaviour of code
        @log_call_to proc_a
        @reroute_call_to proc_b,proc_c

        ; The code
        mov eax,1

        call proc_a

        mov eax,2

        call proc_d

        mov eax,3

        call proc_b

        mov eax,4

        call proc_a

        ret

proc_a:

        ret

proc_b:

        ret

proc_c:

        ret

proc_d:

        ret
    
This can be far more complicated for other tasks but there is a lot that can be done by the macro stage of FASM.

[The same idea can be applied to OO and I've created macro driven interfaces before; classes are more complicated but equally possible]
Post 13 Jan 2012, 19:38
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


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

Powered by rwasa.