Re: assembly language and reverse engineering


"Wolfgang Kern" <nowhere@xxxxxxxx> wrote in message
news:fjp0eg$ak5$3@xxxxxxxxxxxxxxxxxxxxxxxx

"cr88192" wrote:

[...GPU's]
This graphic chips, with their internal 128-bit bus and the hardwired
logic circuits, are already abused for other than graphic matrix calc.

Whenever we get enough information how all these different chips work
(seems only two main vendors may survive the battle anyway), we will
have to update our tools. Hard times for the C-camp :)

my hope is that we are not burdened with having to use GPU-specific stuff
for general programming.
I would much rather see bulk-parallelism being done for side-versions of
the > main processors (hopefully, in a much more standardized manner, eg,
all the
processors using more-or-less the same instruction set, and all this
being
at least reasonably well standardized...).

Yeah, let our wishes reach all designers and merchants involved in this!


Intel has made something like this (at least, I think, the things are x86).
their view of the future is now one where many-core systems will offer
ever-increasing power.

if/when this will become common, I don't know.


[..compilers]
It's rumoured that C-compilers are fully platform independent, but when
I look at my OS which doesn't follow the C-calling convention nor any
other stack-polluting-parameter-copy-passing method, then my question
is: can your compiler or any C,C-/+ variant be configured for a
"strict arguments in registers" and
"arguments by pointer in register" and
"several return arguments in registers" and
"return arguments to struct pointed to by register" and
"return comparision results/error-indication by flag-status",
or would I need to write my own C-compiler ?

to do all this, my compiler would probably need at least some fairly
heavy
modification for all this.
my compiler follows CDECL, and is generally fairly heavily based in the
assumptions of CDECL-like conventions (also supports STDCALL, ... but we
can > ignore this).

now, cdecl generally passes args on the stack, and uses an implicit extra
arg for handling struct return (slightly compiler, and compiler version,
specific, as sometimes the compiler implementors decide to return small
structs in regs, SSE regs, ... so the conventions are not always entirely
consistent).

using flags for return status, would be a very problematic (and
doubtfully
useful) feature.

doubtfully useful ?
I think it's just a matter of definition, I use somthing like:
CY = error ;other flags may indicate the cause
NC = OK ;other flags can hold additional info ie:
Z = equal/zero S = sign/below zero O=.. AC=.. P=..
There is 'some' power in SETcc/CMOVcc beside Jcc right after a CALL.


yes, but there are other, more common ways of supporting this kind of info.
most people who call C functions, do so from C, and for C.


I once considered implementing a "modified core" (basically, this would
use
heap-based memory for everything and compile code using a CPS-based
structure), but I never really implemented this (it would allow good
performance for compiling functional languages, but would somewhat hurt
normal C code...).

otherwise, the usual answer for interfacing C with tweaky/custom
assembler
code is this:
write interface stubs.

The latter could be option, but I'm afraid of loosing too much
performance then.


that is a cost I guess...

however, C code is C code, with performance that is mediocre even when
optimized.

C code is comprable to hand written assembler for "Joe-Blow
just-get-this-crap-over-already" code, but much beyond this, hand written
code has the edge (as humans tend to have somewhat better register
allocation and flow-prediction abilities than the compiler...).

these costs are inherent.

actually, in my case, it is possible a future compiler will no longer use
the more 'traditional' control flow/framing mechanisms, but will instead pay
(in terms of slightly higher overhead for really simple code), and make use
of a CPS-style code structuring.

reason:
this structure allows a lot of things that are problematic and expensive
with the more traditional approaches (tail-call-optimization, more advanced
scope handling, continuations, soft threading and work queueing, ...).

the big problems are this:
CPS is more complicated;
CPS makes interacting with existing code a little uglier (use of multiple
amd hybrid calling conventions);
....


__
wolfgang





.

Relevant Pages

  • Re: Naming typedefs
    ... problem that a scalar could be returned in the A register ... to have waste precious cpu cycles copying the struct there ... of the hardware or twentieth century compiler technology. ... # to include the header defining it into every other header (assuming ...
    (comp.unix.programmer)
  • Re: C/C++ Compilers Optimization Failed
    ... an example of using C/C++ code, but we focus on x86 assembly deeply. ... > struct RGB ... The compiler then would automatically handle the ... I don't think that 3 bytes will fit into 32-bit register because stored ...
    (comp.lang.asm.x86)
  • Re: Returning a struct from a function - strange behavior
    ... structs of 8 bytes or less are returned in a register, ... The compiler could simply move the value of blah.a from ... (and in this case arrays). ... to access fields of a struct returned from a function (or to index ...
    (comp.lang.c)
  • Re: [CodeGallery] MFC MD5 Calculator
    ... was no mechanism for returning OTHER than int. ... We found when we produced a C compiler that it would not have market acceptance because ... As it turned out, it had optimized register ... struct Point3 ...
    (microsoft.public.vc.mfc)
  • Re: switch statement, was compiler, status...
    ... Primary Register, Secondary Register, ... Stack, and abit of storage does it. ... This version of Small-C is copyrighted as a revision to Ron Cain's ... Croatia) is "Calculator Compiler" by Senko Rasik. ...
    (alt.lang.asm)