Re: assembly language and reverse engineering


"Wolfgang Kern" <nowhere@xxxxxxxx> wrote in message
news:fjenbv$6nd$1@xxxxxxxxxxxxxxxxxxxxxxxx

"cr88192" wrote:

:) You both seem to be right from the very point of view.
yeah, seems so.
difference in perspective.

But if I look at my own code and when I remember what I found
in windoze kernels & drivers, there is a lot of 16-bit code
beside the VM86-DOS & BIOS-calls within an 32-bit OS.

ie: most of my IRQ-routines [KEY/mouse/COM/LPT] are just 16-bit
code parts, working identical in RM and PM, while all Exceptions
use 32-bit code regardless if it run PM16, PM32, trueRM or BigReal,
even the latter two need transite/backlink to PM32.

You are right for most tools just lack on the ability to create
mixed 16/32-code and many cannot even workout an 67h override,
and Herbert is right in that a CPU doesn't care at all about
C-conventions nor the 'so common' code practice.

yes. though possible, such a tool would be more complicated.
and, in my case, since anymore I operate almost purely within either
windows or linux, I lack much reason to really do much of anything in
real mode(yet my assembler supports it, for who knows what reason I
decided to implement it...).

A good reason may be just to have this opportunity.


ok.

As long boot and BIOS use 16-bit code, I see 'some' needs to
learn 16-bit ASM, best at start because it's the easier mode,
and after including all 66/67h opportunities in the lessons
there is little left to explain how PM32 works.

yes, and apart from GDT, IDT, Page Tables, ... there is not a whole lot
to explain (at least in terms of the processor).

Right, 32-bit operands and PM-addressing modes work also in RM.


yes, just they are typically not used as such.

afaik, there is also a slight issue on the 386s, but was changed in the 486s
(I think).
afaik:
operations like mov, add, ... on 16 bit operands, simply ignored the upper
half of the register.

later on this was changed, so that such operations typically auto-zero the
upper half.

in any case, this could be a possible issue when dealing with mixing 16 and
32 bit addressing, as one has to be sure there is not garbage in the upper
half of the reg.


in some cases, SSE leaves similar issues, and I suspect that in some cases
my compiler sacrifices a little bit of performance being unsure what is
lurking in the upper parts of the reg...

some operations auto-zero the upper half, some don't.

one has to end up in some cases using vector operations to clear parts of
the reg, to invert signs, ...

many do some things that hardly make much sense (in particular, 'shuf' and
friends). would have made more sense if the component reorganization, and
swapping between regs, were done in different opcodes.

at present, I have to do things like:
movps xmm3, xmm0
shufps xmm3, xmm3, 0x1B

when a single opcode for this would have been nice.

likewise, shuf also sucks for exchanging values between registers as well...


at times though, it is at least a little sad that prefixes can't allow
me to use long-mode features in 32-bit PM (more and wider regs would
have been nice, but would require a prefix to escape REX...).

I'm too a bit disappointed by this 64-bit solutions, but it was perhaps
the only way to keep 16/32-bit modes and add something new within one
chip.
One day we may have pure 64's and can forget all the trouble with oldies.


yes, ok.


sadly, for actual long mode, I never really did get around to finishing
compiler support...

I see it as another CPU, even a heavy detouring link to/from long<->legacy
is possible.


yeah.
part of the problem here is, for x86-64 (linux and friends at least) they
adopted an awkward calling convention, which would be required for
interfacing with existing code on linux.

I would have much rather seen a straightforward conversion of the 32-bit
CDECL, or at least using the stack for passing args to varargs functions.
no, they have to use some funky variant of the 'register' convention, as the
basic convention...


it would be interesting to see though the bizarre beast that would be
a C compiler targetting big-real mode.

:) I can imagine the loud cry in the C-camps ...


yes...


another interesting hypothetical beast:
a massive multi-core mini-386 or 486 based processor.
each mini-core would contain essentially a stripped-down 486 style
processor:
x86, but no RM, MMU, or segmentation (could also use a partly reduced
instruction set).
this would be for simplifying implementation (I will assume that
supporting RM, the MMU, Segmentation, ... probably adds more than
a little complexity).

so the processor(s) would use a shared flat address space. each core
would boot at a constant address in something resembling 32-bit PM.

a main processor (full x86) would be responsible for initializing all
the others (the others would likely be a special processor, likely
plugging into a secondary processor socket).

this could be mapped somewhere in memory (would likely require some
form of OS-awareness).

...

point: if done well, something like this could add drastically to raw
processor power (say, if I suddenly had, 100 or so 2GHz 486's running
alongside an Athlon64 X2 or similar...).

of course, likely a big problem with something like this would be memory
bandwidth...

and, of course the biggest problem:
I have no way of making such a beast (even some lame FPGA version...).

so, all just hypothetical anyways...

An interesting thought anyway...
From time to time I watch what's new in AI-research, and I think the
idea of smaller distributed/decentralized units will finally win against
huge processors. We find it particular already in speach2txt engines and
other 'thinking' devices used for mechanical handycapped support robots.


yes.

Intel has made some interesting experimental chips (an 80 core beast pulling
off several TFLOPS on a single die, presumably x86, but it didn't really say
anywhere...).


looked up some info, including the compiler extensions they are using for
programming on the thing.
can't say I am terribly compelled with the programming model.

basically, rather than branching out code, they emphasize magically parallel
bulk vector operations, and expect other parallelism to be exploited
implicitly (this seems weak, as, as with traditional compiler optimization,
the compiler is likely to miss cases a half-knowlegable programmer coud
"drive a truck through"...).


yeah, I feel a little uncertain that the primary use for parallelism is
going to be in doing lots of huge matrix multiplies and vector additions...

they propose this as being applicable to gaming, and I am like, errm, mostly
gaming involves whole bunches of small vectors and matrices, not some small
number of obscenely huge ones...


I would much rather see a semi-explicit approach (basically, adding in
special tokens in some places that indicate alterations in flow-behavior).


basically:
rather than doing a for loop, and having the compiler figure out whether or
not it can be parallelized, we can do something like this:
for!(i=0; i<64; i++)
...

and this '!' tells the compiler, very explicitly, that this would be a good
point to branch (aka: for a for loop, each iteration may optionally be run
in its own thread).

likewise, in my usual semantics:
foo!(...);

indicates to call the function but not bother waiting for it to return.

if these are used in some way that violates determinism, so be it (at least
it is slightly less awkward than full explicit threading).

some synchronization primitives could be built into the variables and
functions themselves, possibly by using compiler keywords.

__serial {
//some code that can only be run in serial
};

void __serial foo()
{
//function itself is serializing
}

....


of course, this does mean, that if the coder does not use any explicit
constructs, than either the program is serial, or the compiler has to fall
back to the sort of deterministic parallelism that Intel proposes...


__
wolfgang





.

Relevant Pages

  • Re: assembly language and reverse engineering
    ... upper half of the register. ... however, the exact conventions are not, and at some places, my compiler is ... can't say I am terribly compelled with the programming model. ... I suspect, the main use for parallelism, in PCs, is not going to be in doing ...
    (alt.lang.asm)
  • Re: Vista security
    ... yeah. ... C being the only really "general" language I have. ... write a full C++ compiler, ... I am going to fork my code base, back track and see if I can get GCC ...
    (comp.lang.misc)
  • Re: help need in develop dll for use in pocket pc
    ... Yeah, you'll have to make some decisions. ... I think the Dinkumware library (w/ STL) is around $600. ... Intel has a compiler for eVC which is better than the one ...
    (microsoft.public.pocketpc.developer)
  • Re: 0xdeadbeef vs 0xdeadbeefL
    ... compiler doesn't error about it is because it's not an error. ... If you want unsigned chars don't be lazy, ... Yeah it uses LibTomCrypt. ...
    (Linux-Kernel)
  • Re: 2004-2006 EXEblah 2 years uncracked
    ... It was someone commenting on a good product and ... Should I ask which commercial C compiler works best? ... Yeah, it also means I have integrity and a moral compass. ... recently offered work at ATI [they tried to poach me from my current ...
    (sci.crypt)