From: o///annabee on
P? Tue, 24 Jan 2006 01:58:16 -0500, skrev Frank Kotler
<fbkotler(a)comcast.net>:

> Funny no one has done it. Perhaps they lack Betov's "vision"...

Anyway. Why do you think it could not be done?

> Best,
> Frank

From: Frank Kotler on
\\\o///annabee wrote:

....
> Anyway. Why do you think it could not be done?

Jesus! This is where I came in...

Since I'm not familiar with other architectures, I'm not a good one to
give you a concrete example of the problems you'd encounter. It might be
instructive to imagine doing this from some other architecture to x86.
Here's some ppc code snatched at random from the "arch" directory. There
exists an assembler (Gas) which makes ppc opcodes out of this. How would
you go about altering Gas to generate x86 opcodes from this?

[snip - it's GPL]
.text

/*
* Use the BAT0 registers to map the 1st 8MB of RAM to 0x90000000.
*/
.globl setup_bats
setup_bats:
mfpvr 3
rlwinm 3,3,16,16,31 /* r3 = 1 for 601, 4 for 604 */
cmpi 0,3,1
lis 4,0x9000
bne 4f
ori 4,4,4 /* set up BAT registers for 601 */
li 5,0x7f
b 5f
4: ori 4,4,0xff /* set up BAT registers for 604 */
li 5,2
mtdbatu 3,4
mtdbatl 3,5
5: mtibatu 3,4
mtibatl 3,5
isync
blr

/*
* Flush the dcache and invalidate the icache for a range of addresses.
*
* flush_cache(addr, len)
*/
.global flush_cache
flush_cache:
addi 4,4,0x1f /* len = (len + 0x1f) / 0x20 */
rlwinm. 4,4,27,5,31
mtctr 4
beqlr
1: dcbf 0,3
icbi 0,3
addi 3,3,0x20
bdnz 1b
sync
isync
blr

Don't ask me what in hell it does, you were the one who claimed it was
"simple"! I may have selected code which *does* translate easily to x86
- perhaps someone familiar with ppc will tell us if this is the case...

Best,
Frank
From: Betov on
Frank Kotler <fbkotler(a)comcast.net> ?crivait news:ULedndj42Z-iekjeRVn-
uQ(a)comcast.com:

> Don't ask me what in hell it does,

Same for me. :)))))

> you were the one who claimed it was
> "simple"!

No. Half said that the _idea_ was simple. He did not said
(and neither said i) that it would be simple to implement.

> I may have selected code which *does* translate easily to x86
> - perhaps someone familiar with ppc will tell us if this is the case...

This does not, in any way answer to the question about
_why_ outputing equivalent substitutions (even if several
required for one, and therefore _evidently_ "no more
Assembly"),... could not be done.

Why i have this idea is because of the commercial explosure
of the small pocket computers, with Processors like ARM...
The costs are now so incredibly low, that this is becoming
an interresting "side-market" for many things we develop on
PCs. So, why wouldn't it be possible to give a try to something
like this. Admiting there would be some real impossibility, this
would be, at least a wonderful help for creating a port, in true
Assembly (in such a case), with a signifive "partial automation"
of the port job.

As you know the x86 Opcodes are several hundreads, but, when
you disassemble anything, all you see, is around 20 instructions
(a little bit more if there are intensive FPU calculations...).
So which example could be found, in real life, that could not
be applied such substitutions, because of completely missing
concept(s) as a given bu the x86 Mnemonic?

The first thingie, i take a look about, is this Arm thingie
(that is effectively sold with Windows OS). A quick look does
not show to me any "can't do"... All i see tends to show me the
reverse, that is, that the equivalencies are so evident, that,
maybe, even true Assembly Substitutions could be possible and
therefore, that the "Ported Assembly" could eventualy be
very close to true Assembly.

Again, you insist strangely on the "No more Assembly" point,
which is a quite absurd thing to say to me, as i say exactely
the same, if there is no 1:1 Substitution for such and such.

My point is not with making true Assembly Processors
substitutions if not possible. My point is that without "Ported
Assembly" i cannot have any of my Applications runing on such
"market niches" (unless i rewrite it all, one time for each).
Where would the substitutions idea fail in real world? The
only answer i got, up to now, was an example with direct usage
of the Debug Registers, that would not exist on "xxxx Processor".
Well, not exactely what we would call an "everydays real world
Apps", is it? So, what else?


Betov.

< http://rosasm.org >








From: Frank Kotler on
Betov wrote:
> Frank Kotler <fbkotler(a)comcast.net> ?crivait news:ULedndj42Z-iekjeRVn-
> uQ(a)comcast.com:

[ppc code]
>>Don't ask me what in hell it does,
>
> Same for me. :)))))

Well, perhaps neither of us is qualified to even be having this
discussion. But that won't stop us! :)

Seriously, I *don't* know enough about other architectures to be able to
come up with problems you'd have in "real world" code. I've gotten the
impression that there are some. I suppose it depends on "which
architecture".

>>you were the one who claimed it was
>>"simple"!
>
> No. Half said that the _idea_ was simple. He did not said
> (and neither said i) that it would be simple to implement.

Okay, the idea is simple. The idea is obvious. No one has implemented
it. "Too" difficult to implement? Maybe...

>>I may have selected code which *does* translate easily to x86
>>- perhaps someone familiar with ppc will tell us if this is the case...
>
> This does not, in any way answer to the question about
> _why_ outputing equivalent substitutions (even if several
> required for one, and therefore _evidently_ "no more
> Assembly"),... could not be done.

Okay, as long as we're agreed that it's "no more assembly". As I
understand it, you're talking about combining an assembler and a
compiler into a single executable. I suppose this could be done. Whether
it's a good idea is probably a matter of opinion. I'm inclined towards
"do one thing, and do it well". You seem to like "fully integrated"
thingies, so our opinions might differ...

> Why i have this idea is because of the commercial explosure
> of the small pocket computers, with Processors like ARM...
> The costs are now so incredibly low, that this is becoming
> an interresting "side-market" for many things we develop on
> PCs.

Right. I don't know ARM, but there was an idea (some time ago) to extend
Nasm to ARM. I get the impression that it's fairly "close" to x86. If
so, there may be enough "equivalent" instructions (or few enough
"unequivalent" instructions) to make something like this possible.

> So, why wouldn't it be possible to give a try to something
> like this.

It would be possible to give a try to *anything*. "Nothing ventured,
nothing gained." (I just don't think it'll work... well)

> Admiting there would be some real impossibility, this
> would be, at least a wonderful help for creating a port, in true
> Assembly (in such a case), with a signifive "partial automation"
> of the port job.

Maybe... You mention that ARM has 16 registers. If our "cross asspiler"
does the most "direct", "assembler-like", conversion of x86 source, it
may not result in good register allocation on ARM. The existance of more
registers might make a different algorithm possible. If we make this
tool more "compiler-like", treat "eax" and "ebx" as "just variables",
and let the compiler assign 'em to ARM registers as it will, we might
get better code. At this point, I'm not sure what the advantage would be
of using x86 asm as the syntax...

.... unless, of course, you had a bunch of x86 asm code on hand. :) I
suppose what you've got in mind is an addition to RosAsm whereby it
would spit out apps to run on pocket devices running ARM and... Windows
CE is it? That *would* be cool, if you could pull it off!

> As you know the x86 Opcodes are several hundreads, but, when
> you disassemble anything, all you see, is around 20 instructions
> (a little bit more if there are intensive FPU calculations...).
> So which example could be found, in real life, that could not
> be applied such substitutions, because of completely missing
> concept(s) as a given bu the x86 Mnemonic?

I don't know specifics. I suppose any portabilty involves a "lowest
common denominator". Maybe if you limit yourself to the subset of
instructions that *do* have an equivalent... call it LCDasm... I don't
think it'll fly. I think asm programmers want to be *able* to use all
those hundreds of instructions, even if they don't actually use 'em. But
I could be wrong...

> The first thingie, i take a look about, is this Arm thingie
> (that is effectively sold with Windows OS). A quick look does
> not show to me any "can't do"... All i see tends to show me the
> reverse, that is, that the equivalencies are so evident, that,
> maybe, even true Assembly Substitutions could be possible and
> therefore, that the "Ported Assembly" could eventualy be
> very close to true Assembly.

That may be true if we limit the discussion to ARM. I really don't know.
The "problem instruction"(s), if any, won't be the first thing you see.
Possibly the last...

> Again, you insist strangely on the "No more Assembly" point,
> which is a quite absurd thing to say to me, as i say exactely
> the same, if there is no 1:1 Substitution for such and such.

Strangely, I thought it was *you* who was calling this assembly.

> My point is not with making true Assembly Processors
> substitutions if not possible. My point is that without "Ported
> Assembly" i cannot have any of my Applications runing on such
> "market niches" (unless i rewrite it all, one time for each).

This is where the C affectionados have their say! :)

> Where would the substitutions idea fail in real world? The
> only answer i got, up to now, was an example with direct usage
> of the Debug Registers, that would not exist on "xxxx Processor".
> Well, not exactely what we would call an "everydays real world
> Apps", is it? So, what else?

Well, I don't know. All it takes is one. Maybe not, if you're willing to
switch into "compiler mode" and generate "whatever it takes" to get the
result, when/if needed... As noted above, this might not generate
optimum code. You'd be "thinking like an x86 asm programmer" rather than
"thinking like an ARM asm programmer". At that, the result might compete
with available code - some of it probably isn't hard to beat!

Can't hurt to look into ARM more closely, and see if you still think
it's possible/practical. Learning is never wasted! :)

Best,
Frank

From: sevagK on

Frank Kotler wrote:
>
> Can't hurt to look into ARM more closely, and see if you still think
> it's possible/practical. Learning is never wasted! :)
>
> Best,
> Frank

If I remember correctly, someone already did an ARM port for FASM.
Check it out on the fasm forum.

-sevag.k -=Kain=-
www.geocities.com/kahlinor

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Prev: Check out POASM
Next: Bad habits