Fantastic, portable assembler. 
Author Message
 Fantastic, portable assembler.

Hi, guy's (and so respectable readers also :).

At the begin of de year somebody (forgot his name) proposed to
make
a language which should be as close to assembler as it possible at all,
but ... it must be an universal language for all architectures,
i.e. portable assembler.
Such idea sounds so naive (I love dis word).
But, in a true it have sense.
Look, when you code something in assembler you tend to make an algorithm

as much effective as you can do. (I mean when you code in assembler not
because you haven't C compiler :)
But everybody know that assembler for POWER and for MC680?0* is
absolutely
different.
Then when you want to port graphical application from one processor to
another
usually you have remake an assembler code,
even in that case when such processors works with absolutely similar
OS with same environment.
As I told yet, assembler code used in that cases when efficiency
required
most of all (and when efficiency of C-code is so weak).

I think why don't make something in a middle between hight-level
languages
(like C or fortran) and assembler. In a middle from de such points of
view:
1. comfort of coding.
2. efficiency of result code.
3. portability.

And I create such conception I call it universal assembler.
It have such abstraction like:
 variables
 functions
 formal/actuall parameters
(that was taken from Fortran)
also it have typical assembler abstraction:
 flags
 addressing non - typified variables

average view of syntax:

---------------------------variable
declarations-----------------------------
byte ?name>,...;
byte2 ?name>,...;
byte4 ?name>,...;
byte8 ?name>,...;
pointer_code ?name>,...; // address of procedure, jump, ect
                         // also could decelerated as assembler marks
pointer_data ?name>,...; // address of data (*void)
pointer_data ?type> ?name>,...; // addressing of typed variable
area[?number of memebrs>] of ?type> ?name>,...;
                                //"massive" AKA "area" declaration
int ?name>,...; // an integer, like in C size dependent by
implementation :)
----------------------------using of
variables-------------------------------
For variable "A"

A - value of variable A
[A] -  memory pointed by variable [A]
(type)[A] - access variable with a "type" and and location A.
A[B] - unit number b in the area pointed by variable A
---------------------------program
structure----------------------------------
jump ?mark>
call ?mark>
if    ?flag>
ifn   ?flag> // if not flag
endif

Construction ("if/ifn" ... "endif") have lower priority as
"jump/call/return"
and first meta-instruction "jump/call/return" inside such construction
close it
(like in other case "endif" did).

function ?name> (?output_variables>) (?input_variables>)
// "name" is a constant with a type "pointer_code"
....
return

halt
(abstraction of "function" needed for ordering of relating of variables)
and
nothing else.
--------------------------- and ....
-----------------------------------------
(where "var" - variable "var.r" variable with result
 when one variable missed result returns into the first operand)
add ?var.r>,?var>,?var>
sub ?var.r>,?var>,?var>
div ?var.r>,?var>,?var>
divr ?var.r>,?var.r>,?var>,?var> //division with a rest.
mult ?var.r>,?var>,?var>
not ?var.r>,?var>
or ?var.r>,?var>,?var>
xor ?var.r>,?var>,?var>
and ?va.rr>,?var>,?var>
shift_r ?var.r>, ?var> //right - bit shift
shift_l ?var.r>, ?var> //left - bit shift
roll_r ?var.r>, ?var> //roll right
roll_l ?var.r>, ?var> //roll left
roll_r_c ?var.r>, ?var> //roll right through C-flag
roll_l_c ?var.r>, ?var> //roll left through C-flag
inc ?var.r>, ?var>
dec ?var.r>, ?var>
move ?var.r>, ?var>
-----------------------------falgs--------------------------------------

C, Z - standard
DC, AC, (and some more) ... additional to use it programmer must mark it

it near that instruction which modify it, and he/she must use it before
first instruction which could modify it (even if it not marked)
Example 1:
....
byte4 b;

    sub b, 1    // b=b-1
    ifn Z       // if result not Zero
     jump loop  //                    jump on a "loop" again.
    endif       // added for order :)
....

Example 2:
....
byte4 b;
int c;

    sub b, 2 : AC,DC // mark that flags modified here
    if AC
      jump loop
                     // "endif" not required after "jump"
    if DC
      call dexim (c) (b,c) // call function "dexim"
....
-------------------------
Standard constant:
DIGITS_NUMBER
value 4, 8, 16, 32, 64
//but I afraid that 4-bit processors do not require it. :)
DATA_PAGE
value - (type: pointer_data) start address of data area.
CODE_PAGE
value (type: pointer_code) start address of code area
--------------------------
In addition I want ot say that create it after comparison of theseveral
assemblers.
But perhaps it need preprocessor like C/C++ have.
And I afraid program in such code could be portable between processors
with same digits number only. :(
-------------------------------
Authors.
Author of naive proto-idia:
        Jonathan Neve

Author of such conception:
        an Alternative (real name Myhajlo Bloha or Myhajlo Mythrofanov)
        anarchist, inventor, ect...
        telephone: in Kyiv 550-8285 (ask Misha)
        mail:   Myhajlo Mytrofanov
                     Serafimivycha st. #3 apt. 127
                     02125 Kyiv
                     Ukraine

        (better write to both,
        it would made probability that I'll read at leas from one)

Want somebody create an implementation of such conception ?



Sun, 03 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.
Hi, guy's (and so respectable readers also :).

At the begin of de year somebody (forgot his name) proposed to
make
a language which should be as close to assembler as it possible at all,
but ... it must be an universal language for all architectures,
i.e. portable assembler.
Such idea sounds so naive (I love dis word).
But, in a true it have sense.
Look, when you code something in assembler you tend to make an algorithm

as much effective as you can do. (I mean when you code in assembler not
because you haven't C compiler :)
But everybody know that assembler for POWER and for MC680?0* is
absolutely
different.
Then when you want to port graphical application from one processor to
another
usually you have remake an assembler code,
even in that case when such processors works with absolutely similar
OS with same environment.
As I told yet, assembler code used in that cases when efficiency
required
most of all (and when efficiency of C-code is so weak).

I think why don't make something in a middle between hight-level
languages
(like C or Fortran) and assembler. In a middle from de such points of
view:
1. comfort of coding.
2. efficiency of result code.
3. portability.

And I create such conception I call it universal assembler.
It have such abstraction like:
 variables
 functions
 formal/actuall parameters
(that was taken from Fortran)
also it have typical assembler abstraction:
 flags
 addressing non - typified variables

average view of syntax:

---------------------------variable declarations-----------------------------
byte <name>,...;
byte2 <name>,...;
byte4 <name>,...;
byte8 <name>,...;
pointer_code <name>,...; // address of procedure, jump, ect
                         // also could decelerated as assembler marks
pointer_data <name>,...; // address of data (*void)
pointer_data <type> <name>,...; // addressing of typed variable
area[<number of memebrs>] of <type> <name>,...;
                                //"massive" AKA "area" declaration
int <name>,...; // an integer, like in C size dependent by
implementation :)
----------------------------using of variables-------------------------------
For variable "A"

A - value of variable A
[A] -  memory pointed by variable [A]
(type)[A] - access variable with a "type" and and location A.
A[B] - unit number b in the area pointed by variable A
---------------------------program structure----------------------------------
jump <mark>
call <mark>
if    <flag>
ifn   <flag> // if not flag
endif

Construction ("if/ifn" ... "endif") have lower priority as
"jump/call/return"
and first meta-instruction "jump/call/return" inside such construction
close it
(like in other case "endif" did).

function <name> (<output_variables>) (<input_variables>)
// "name" is a constant with a type "pointer_code"
....
return

halt
(abstraction of "function" needed for ordering of relating of variables)
and
nothing else.
--------------------------- and .... -----------------------------------------
(where "var" - variable "var.r" variable with result
 when one variable missed result returns into the first operand)
add <var.r>,<var>,<var>
sub <var.r>,<var>,<var>
div <var.r>,<var>,<var>
divr <var.r>,<var.r>,<var>,<var> //division with a rest.
mult <var.r>,<var>,<var>
not <var.r>,<var>
or <var.r>,<var>,<var>
xor <var.r>,<var>,<var>
and <va.rr>,<var>,<var>
shift_r <var.r>, <var> //right - bit shift
shift_l <var.r>, <var> //left - bit shift
roll_r <var.r>, <var> //roll right
roll_l <var.r>, <var> //roll left
roll_r_c <var.r>, <var> //roll right through C-flag
roll_l_c <var.r>, <var> //roll left through C-flag
inc <var.r>, <var>
dec <var.r>, <var>
move <var.r>, <var>
-----------------------------falgs--------------------------------------

C, Z - standard
DC, AC, (and some more) ... additional to use it programmer must mark it

it near that instruction which modify it, and he/she must use it before
first instruction which could modify it (even if it not marked)
Example 1:
....
byte4 b;

    sub b, 1    // b=b-1
    ifn Z       // if result not Zero
     jump loop  //                    jump on a "loop" again.
    endif       // added for order :)
....

Example 2:
....
byte4 b;
int c;

    sub b, 2 : AC,DC // mark that flags modified here
    if AC
      jump loop
                     // "endif" not required after "jump"
    if DC
      call dexim (c) (b,c) // call function "dexim"
....
-------------------------
Standard constant:
DIGITS_NUMBER
value 4, 8, 16, 32, 64
//but I afraid that 4-bit processors do not require it. :)
DATA_PAGE
value - (type: pointer_data) start address of data area.
CODE_PAGE
value (type: pointer_code) start address of code area
--------------------------
In addition I want ot say that create it after comparison of theseveral
assemblers.
But perhaps it need preprocessor like C/C++ have.
And I afraid program in such code could be portable between processors
with same digits number only. :(
-------------------------------
Authors.
Author of naive proto-idia:
        Jonathan Neve

Author of such conception:
        an Alternative (real name Myhajlo Bloha or Myhajlo Mythrofanov)
        anarchist, inventor, ect...
        telephone: in Kyiv 550-8285 (ask Misha)
        mail:   Myhajlo Mytrofanov
                     Serafimivycha st. #3 apt. 127
                     02125 Kyiv
                     Ukraine

        (better write to both,
        it would made probability that I'll read at leas from one)

Want somebody create an implementation of such conception ?



Sun, 03 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.
Such an idea has no real purpose.  C does everything that a portable
assembler could hope to do.

A portable assembler cannot include instructions which will only work on
one architecture.  So most of the benefit of assembly (things like
altering status registers, privilege levels, conditional moves, MMX,
optimising, etc) are out.

It also could not include some of the benefits of C, like data typing,
true structure, tremendous portability.  And before you say "yes it
could", such a program would be merely C with a different syntax.

Also, is your assembler going to use a load/store model or a CISC model?
How on Earth would it produce code that was optimised across all
architectures?

A cross-platform assembler would achieve none of the aims for which
assembler is commonly used.

--------------
Richard Cavell
Melbourne University Medical Student
Debater, Chess Player, etc.

Newsgroups - Please copy your replies to me via email.  (Server problems).



Mon, 04 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.

Quote:

> Such an idea has no real purpose.  C does everything that a portable
> assembler could hope to do.

I would respectfully disagree, Richard. There is a fascinating language called  PL/X
used by IBM and a few of its customers. This language is a thin wrapper around
370/390 assembler but makes it very easy to code modules for object-oriented
languages. The syntax which PL/X provides has largely to do with control flow
and structure/object definitions.

The PL/X idea could be applied to any instruction architecture. I prototyped a similar
language myself years ago for 80x86 (before I'd heard of PL/X!).

--
Jack J. Woehr                 # Ceterum censeo
PO Box 51, Golden, CO 80402   # in herbas belli
http://www.well.com/~jax/rcfb # ab idem desistamus.



Mon, 04 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.



Quote:
> Such an idea has no real purpose.  C does everything that a portable
> assembler could hope to do.

Wellllll, that's a really strong statement.  C does certain things
relatively
poorly (from a low-level point of view), so I'm not sure I'd make a
statement
that is this strong (though I tend to agree with your overall premise).

Quote:

> A portable assembler cannot include instructions which will only work on
> one architecture.  So most of the benefit of assembly (things like
> altering status registers, privilege levels, conditional moves, MMX,
> optimising, etc) are out.

Well, it could if the user were willing to put up with a compilation of
that code into semantically equivalent (though much slower and larger)
code on the different architecture.   Of course, this would defeat the
purpose of using assembly, but...

Quote:

> It also could not include some of the benefits of C, like data typing,
> true structure, tremendous portability.  And before you say "yes it
> could", such a program would be merely C with a different syntax.

Existing assemblers provide the benefits of data typing and possibly
"true structure" (depending on whether I've interpreted the meaning
properly here).  Portability of course, is the stated purpose of this
project.  I would argue with the "C with a different syntax" comment.
Certainly the result would be higher level than traditional assembly
language, but that's not to suggest it has to be as high level as C.

Consider the Java Virtual Machine for a moment.  "Assembly code"
for the JVM is portable and definitely lower level than C. Were an
assembler be written for the JVM that supported data typing and
"true structure" I would argue that the result would achieve those
three goals and not merely be C with a different syntax.  Now whether
there would be any benefit, performance wise, to using this is
another question altogether.

Quote:

> Also, is your assembler going to use a load/store model or a CISC model?
> How on Earth would it produce code that was optimised across all
> architectures?

By writing an optimizer :-)

Seriously, though, this is a big area of research today (moving code from
one architecture to another).  There is no fundamental reason to suggest
that x86 code cannot be compiled "efficiently" onto a different architecture
and vice-versa.  Clearly the code will probably take a performance hit
on comparable performance architectures.  But let's say that I've got some
386-optimized code and I want to run it on an Alpha or Power-PC chip.
It might actually be possible to cross compile this stuff and get halfway
decent performance.

Quote:

> A cross-platform assembler would achieve none of the aims for which
> assembler is commonly used.

Absolutely true.
But that's because most people don't use assembly language to write
portable code!

Randy Hyde
P.S., don't get the idea that I believe a "portable assembler" is
a practical idea.  I'm 100% behind you: there is little need for such
a device because very few people would use it (why bother with
assembly if HLLs are going to produce faster code?).

OTOH, someday the x86 (or pick your favorite) architecture will
finally be gone, or will have diminished to the level of 6502 or Z80
use today.  At that time it would be nice to have a compiler that
translates x86 assembly code into something else.  This isn't
a "portable assembly language" but is somewhat related to this
discussion.  While I wouldn't argue for a portable assembler
(besides, it already exists in the guise of the JVM), I do believe
the need exists to write compilers that translate code from
one architecture to another.



Mon, 04 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.
Amazes me that the 6502 is still being programmed for and implemented in
homebuilt computers.

Quote:


> >Such an idea has no real purpose.  C does everything that a portable
> >assembler could hope to do.

> I use a number of languages, including C and assembly and I can assure
> you that there are indeed things that are difficult or ungainly in C
> that are easier in assembly.  As an example, consider a simple
> multi-byte add -- every micro I've ever worked with has a carry flag
> and an add instruction that can use it.  This makes the propagation of
> the carry flag very simple, but there's simply no such concept built
> into C so it's difficult to write extremely efficient code to
> implement such a thing in C, even with very good optimizing compilers.

> >It also could not include some of the benefits of C, like data typing,
> >true structure, tremendous portability.  And before you say "yes it
> >could", such a program would be merely C with a different syntax.

> By that logic, Pascal, Java and python are all just C with a different
> syntax!  I think you'll find that there are many languages with a
> notion of "type" -- even assembly languages.  For example, TASM and
> MASM both will optionally warn you about applying the wrong type to a
> variable if you ask them to.

> >A cross-platform assembler would achieve none of the aims for which
> >assembler is commonly used.

> Perhaps, but a retargetable assembler (gas might be considered an
> example of this) could allow some measure of portability without
> sacrificing the efficiencies for which assembly is used.  For example,
> the venerable 6502 uses the mnemonic "jsr" while the 80xxx uses "call"
> -- as a trivial example, one could choose one or the other and gain
> one small step toward portability.

> Ed

--

Team2k PC/Palm Pilot Programming Team:
http://ppilot.homepage.com

To email me, remove '3*&' from my email address. This is to deter spam :)



Mon, 04 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.

Quote:

> Such an idea has no real purpose.  C does everything that a portable
> assembler could hope to do.

Not at all.
There is a cases when assembler is really preferable.
First of all it's
1) a graphics
2) sound processing
3) signal processing.
Look algorithm of calculation of harmonics set
in C and in assembler works different.
In assembler much quicker. Even without Motorola's LC or Intel's MMX

Quote:

> A portable assembler cannot include instructions which will only work on
> one architecture.  So most of the benefit of assembly (things like
> altering status registers,

What for you have to modify it ?
In "normal" processors (not an intel's)
all of altering os status register might be collected in small library
which could be unified.

Quote:
> privilege levels,

same.

Quote:
> conditional moves,

Why not ?!
My "if endif" construction allow to do it.

Quote:
> MMX,

MultiMedia suX ? :)
Yes, in current description I miss such tricks.
Look there a lot of several implementation of such idea.
Motorola: MC680?0LC
Intel: MMX,  XMM
AMD: 3Dnow

It might be unified, and united under unified portable syntax.
But I do not think that such things really good deals.
Motorola was firs who did "LC" but they used absolutely
opposite way in PowerPC, and they recommend IBM to simplify
instruction set of POWER.
Look Alpha was quicker as Intel but had no any MMX,
PowerPC (G4) much quicker as any Intel analogues,
and again have no any MMXMM :)

MMX is agony of CISC.

Quote:

> optimising, etc) are out.

What optimizing do you mean ?

Quote:

> It also could not include some of the benefits of C, like data typing,
> true structure, tremendous portability.  And before you say "yes it
> could", such a program would be merely C with a different syntax.

Such tricks lied over pure assembler.
In several kind of pre-compilers.
Such as in macro-assemblers.

Quote:

> Also, is your assembler going to use a load/store model or a CISC model?

It defined but concrete realizing of system which translate "universal
assembler"
to real assembler.
I use abstraction of variables for overcoming such problem.

Quote:
> How on Earth would it produce code that was optimised across all
> architectures?

What ?
Do you ask how to optimize code for all architecture atones ?
It's impossible ofcource.
But any way coding in universal assembler makes applications portable.

Quote:

> A cross-platform assembler would achieve none of the aims for which
> assembler is commonly used.

I want to repeat again.
Not at all.
There is a cases where it is could required.

Quote:

> --------------
> Richard Cavell
> Melbourne University Medical Student
> Debater, Chess Player, etc.

> Newsgroups - Please copy your replies to me via email.  (Server problems).

Ok. I'll.


Tue, 05 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.

Quote:


> > Such an idea has no real purpose.  C does everything that a portable
> > assembler could hope to do.

> I would respectfully disagree, Richard. There is a fascinating language called  PL/X
> used by IBM and a few of its customers. This language is a thin wrapper around
> 370/390 assembler but makes it very easy to code modules for object-oriented
> languages. The syntax which PL/X provides has largely to do with control flow
> and structure/object definitions.

> The PL/X idea could be applied to any instruction architecture. I prototyped a similar
> language myself years ago for 80x86 (before I'd heard of PL/X!).

As I have undertood PL/X is something like FORTRAN.
But I speak about that which is really looks like assembler.
Quote:

> --
> Jack J. Woehr                 # Ceterum censeo
> PO Box 51, Golden, CO 80402   # in herbas belli
> http://www.well.com/~jax/rcfb # ab idem desistamus.



Tue, 05 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.

Quote:
>Such an idea has no real purpose.  C does everything that a portable
>assembler could hope to do.

I use a number of languages, including C and assembly and I can assure
you that there are indeed things that are difficult or ungainly in C
that are easier in assembly.  As an example, consider a simple
multi-byte add -- every micro I've ever worked with has a carry flag
and an add instruction that can use it.  This makes the propagation of
the carry flag very simple, but there's simply no such concept built
into C so it's difficult to write extremely efficient code to
implement such a thing in C, even with very good optimizing compilers.

Quote:
>It also could not include some of the benefits of C, like data typing,
>true structure, tremendous portability.  And before you say "yes it
>could", such a program would be merely C with a different syntax.

By that logic, Pascal, Java and Python are all just C with a different
syntax!  I think you'll find that there are many languages with a
notion of "type" -- even assembly languages.  For example, TASM and
MASM both will optionally warn you about applying the wrong type to a
variable if you ask them to.

Quote:
>A cross-platform assembler would achieve none of the aims for which
>assembler is commonly used.

Perhaps, but a retargetable assembler (gas might be considered an
example of this) could allow some measure of portability without
sacrificing the efficiencies for which assembly is used.  For example,
the venerable 6502 uses the mnemonic "jsr" while the 80xxx uses "call"
-- as a trivial example, one could choose one or the other and gain
one small step toward portability.

Ed



Tue, 05 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.

Quote:

> > one architecture.  So most of the benefit of assembly (things like
> > altering status registers,

> What for you have to modify it ?
> In "normal" processors (not an intel's)
> all of altering os status register might be collected in small library
> which could be unified.

No, the status registers cannot be unified.  Any processor which contains
a 'privileged' subset of instructions will provide those instructions on a
nuts-and-bolts basis to operating systems and the like.  A unified
privileged mode model cannot successfully deal with, say, turning off
Wintel's misaligned data exception when the same cannot be done on a
MC68000.  The RDTSC instruction (used for profiling) cannot be used in
your assembler, as it has no equivalent in the 6502/68000/other processor.

Quote:
> MultiMedia suX ? :)
> Yes, in current description I miss such tricks.
> Look there a lot of several implementation of such idea.
> Motorola: MC680?0LC
> Intel: MMX,  XMM
> AMD: 3Dnow

But it's not the same!  MMX is a specific set of instructions (which are
not necessarily multimedia oriented) which are useful for heavy
optimisation of very limited types of operation.  And you shouldn't mix
them with floating point instructions.  How on Earth does your
cross-assembler produce half-decent MMX code on a PowerPC?

Quote:
> > optimising, etc) are out.

> What optimizing do you mean ?

Optimizing, broadly, is the process of getting programs to run faster with
smaller executable.  It is done by understanding the lowest level of
program operation and simplifying it into something that the processor
will deal with quicker than what the compiler puts out.  Thus you are
hand-compiling with a human brain rather than a compiler's algorithm, if
you like.

If you can write a program that can optimise code better than Visual C++,
I suggest you knock up an implementation and sell it to the myriad game
developers who would kill for an extra frame per second.

If you want to implement it, go ahead - and I'll betatest it for you, I'd
like to see it succeed.  But for the amount of effort and the potential
usefulness, you may as well write an IA64 assembler and optimiser, or an
x86 to IA64 converter, or something.

Richard.



Tue, 05 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.

Quote:
> Such an idea has no real purpose.  C does everything that a portable
> assembler could hope to do.

Far from it!  Not only is assembly sometimes preferred from an efficiency
standpoint as others have pointed out, but there are control structures
that simply cannot be implemented in C.  You can implement something sort
of like them, but you can't write C code that directly translates to the
intended instruction sequence.

A "portable" assembler that is useful for all possible machines is clearly
not possible.  However, if you restrict the target range you possibly could
do something.  I have toyed with the idea for quite some time, but don't
have the time to flesh out the concept -- much less write the code.

And the result might not be anything better than yet another intermediate
compiler language (of course, that might be good enough).

Some questions to consider...

Are all registers virtual?  Can assignments be given to explicit registers?
If so, what happens on a different platform?  What about the number of
registers?

Do you assume little endian, big endian or something in between?

The "basic" instructions are fairly easy, but what about some of the
unusual instructions that can be very handy on some machines, but with no
equivalent on others?  How about problems like condition codes -- do you
one set, a limited number of sets or any number of sets?  Can instructions
be predicated or speculated as in the I64 architecture?

What about privledged instructions?  There is almost no commonality there.

Even if you only wanted to cover the I32 and I64 instruction sets there
would be some severe problems.  The way you write assembler code can vary
drastically between different instruction sets -- even for the same
algorithm.  And, in practice, the algorithm you choose is frequently
influenced by the instruction set.



Tue, 05 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.

Quote:

> In article <Pine.OSF.4.10.10005182047310.15184-100000

> > Such an idea has no real purpose.  C does everything that a portable
> > assembler could hope to do.

> Far from it!  Not only is assembly sometimes preferred from an efficiency
> standpoint as others have pointed out, but there are control structures
> that simply cannot be implemented in C.  You can implement something sort
> of like them, but you can't write C code that directly translates to the
> intended instruction sequence.

Exactly !
I mean same but didn't know how to say it. :)
Dank you.

Quote:

> A "portable" assembler that is useful for all possible machines is clearly
> not possible.  However, if you restrict the target range you possibly could
> do something.  I have toyed with the idea for quite some time, but don't
> have the time to flesh out the concept -- much less write the code.

:(

Quote:

> And the result might not be anything better than yet another intermediate
> compiler language (of course, that might be good enough).

But I do not see closer tool as such assembler :).

Quote:

> Some questions to consider...

> Are all registers virtual?

It's even not registers it's variables.
Yes all of registers are virtual.
It's make translation from "such" to "mormal" assembler much difficuler.
But there is no another way.
Actually I mix Fortran's variables and Assembler instructions.

Quote:
>  Can assignments be given to explicit registers?

No.

Quote:

> If so, what happens on a different platform?  What about the number of
> registers?

> Do you assume little endian, big endian or something in between?

Oh, sorry my english do not allow me to understand such phrase. :( :)
What is "endian" ?

Quote:

> The "basic" instructions are fairly easy, but what about some of the
> unusual instructions that can be very handy on some machines, but with no
> equivalent on others?

Such problem exist not only for assembler,
for C, Fortran and a lot of others languages also.
Solution is optimization.

Look I agree that every concrete program in such assembler
will be most effective for one concrete architechture,
but portable to another.
In such case to the pure "such assembler" could be added specific
instructions.
But every specific instruction must have handle macros which
must be created in pure code.

So there is two solutions.
1. Optimization.
2. Additional handled instructions.

Quote:
>  How about problems like condition codes -- do you
> one set, a limited number of sets or any number of sets?

Wait, what sets you talking about.
A conditional flags ?
There only 3 flags :(
plus and additional I defined only two
but I think we could add another few. :)
About using random bits of random register like flags.
I don't know how to do.
In some processors.
Allow it means get efficiency much lower.
In other prohibit it means get efficient a bit lower.

Quote:
>  Can instructions
> be predicated or speculated as in the I64 architecture?

It's how ? :)

Quote:

> What about privledged instructions?  There is almost no commonality there.

You mean "supperuser"/"suppervisor" instructions.
In any normal OS it isn't necessary.
Because OS care about all of the task where is needed.
In OS design .... there would good deal to do OS
with single source for all architectures, and perhaps it's possible
but I didn't put myself such task when create current
view of universal assembler.

Quote:

> Even if you only wanted to cover the I32 and I64 instruction sets there
> would be some severe problems.  The way you write assembler code can vary
> drastically between different instruction sets -- even for the same
> algorithm.  And, in practice, the algorithm you choose is frequently
> influenced by the instruction set.

Actually I propose only description language which allow to write that
details which gone in C.
Any way it allow enclose program to assembler much as C allow.
Ofcource it do not allow to get same result as with pure assembler.
But have another preferences.
It is portable and might be optimized.

                                  --Alternative.

P.S. Thank you for answer/comments/questions. :)



Tue, 05 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.

Quote:


> > > one architecture.  So most of the benefit of assembly (things like
> > > altering status registers,

> > What for you have to modify it ?
> > In "normal" processors (not an intel's)
> > all of altering os status register might be collected in small library
> > which could be unified.

> No, the status registers cannot be unified.  Any processor which contains
> a 'privileged' subset of instructions will provide those instructions on a
> nuts-and-bolts basis to operating systems and the like.  A unified
> privileged mode model cannot successfully deal with, say, turning off
> Wintel's misaligned data exception when the same cannot be done on a
> MC68000.  The RDTSC instruction (used for profiling) cannot be used in
> your assembler, as it has no equivalent in the 6502/68000/other processor.

Yes, you right.
and P-) b-) I was wrong.
There is a problem.
But there is a lot of application where such assembler could be used
but it do not need modify status.

Quote:

> > MultiMedia suX ? :)
> > Yes, in current description I miss such tricks.
> > Look there a lot of several implementation of such idea.
> > Motorola: MC680?0LC
> > Intel: MMX,  XMM
> > AMD: 3Dnow

> But it's not the same!  MMX is a specific set of instructions (which are
> not necessarily multimedia oriented) which are useful for heavy
> optimisation of very limited types of operation.  And you shouldn't mix
> them with floating point instructions.  How on Earth does your
> cross-assembler produce half-decent MMX code on a PowerPC?

I don't know what is it.
but hope that it's possible some way :)

Quote:

> > > optimising, etc) are out.

> > What optimizing do you mean ?

> Optimizing, broadly, is the process of getting programs to run faster with
> smaller executable.  It is done by understanding the lowest level of
> program operation and simplifying it into something that the processor
> will deal with quicker than what the compiler puts out.  Thus you are
> hand-compiling with a human brain rather than a compiler's algorithm, if
> you like.

I hope I understood you.
Look, I do not think that might exist absolute optimizer.
My "universal assembler" allow to be optimized.
But optimizing and human hand optimal making
do not inter-eliminate themselves, they is inter-additional.
Optimizer get information which is pre-optimized.
And pre-optimized not in formal way, but it need to be optimized in formal
way.

Quote:

> If you can write a program that can optimise code better than Visual C++,

Visual C++ one of the worse optimizers.
Watcom C++ much better.

Quote:
> I suggest you knock up an implementation and sell it to the myriad game
> developers who would kill for an extra frame per second.

:)
Between, my friend game developer have Visual C++
He owe OS/2 and Watcom :)

Look _BEST_ C-compiler for x86 is "gcc"  and it distributed free (under GPL).

Quote:

> If you want to implement it, go ahead - and I'll betatest it for you, I'd
> like to see it succeed.  But for the amount of effort and the potential
> usefulness, you may as well write an IA64 assembler and optimiser, or an
> x86 to IA64 converter, or something.

Thanks for you help.
But I do not want to implement it at all, my business only conceptions. :)
Ofcource I could help, with a treat of my conception.
As a programmer a less a average. :(
Between you could believe or could not but,
Transmitter's "CodeMorphing" was my. How they got it I don't know.

Currently I work at another projects.

- Show quoted text -

Quote:

> Richard.



Tue, 05 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.

Quote:

> A "portable" assembler that is useful for all possible machines is clearly
> not possible.  However, if you restrict the target range you possibly could
> do something.

Fair enough.  Now consider all the machines which are worth writing an
assembler for:

IA64 - definitely
IA32 - definitely
Alpha - probably
PowerPC - probably
68000 - no
6502 - definitely no

The difference between IA64 and IA32 is enough to put real spanners into
the works for the portable assembler, let alone the difference between
IA32 and PowerPC.  In practise, if you're going to target a limited range
of processors, as you suggest, you'll find it difficult to find a range
that covers a limited amount of territory.

If you wanted to make an assembler that compiled for, say, the 6502 and
the 6808, I'd understand, since their instruction sets are similar.  But
the real-world architectures these days are worlds apart.

Quote:
> I have toyed with the idea for quite some time, but don't
> have the time to flesh out the concept -- much less write the code.

As I suggested, it will take millions of dollars of R&D just to get a
decent IA64 compiler IDE up and running.

Quote:
> Are all registers virtual?  Can assignments be given to explicit registers?

This raises another point - of course, some registers are different sizes
on different machines.  Presumably if you moved 2^127 into a register, the
portable assembler would fit the value directly into the Playstation 2's
registers, but will automatically chop it into four pieces for IA-32 and
dump it into the stack.

And CX has a special purpose on IA32.  Try dealing with that.

Quote:
> Do you assume little endian, big endian or something in between?

Like middle-endian?  heh, heh.

Quote:
> Can instructions be predicated or speculated as in the I64
> architecture?

Worry about FMOVcc and XLAT before you worry about speculation.

Richard.



Wed, 06 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.

Quote:

> Thanks for you help.
> But I do not want to implement it at all, my business only conceptions. :)

If you want to do a project, try inventing a new language.  I think any
portable program needs to have elements which are higher-level than
assembler, but you can still keep yourself fairly low-down in the scheme
of things (like C).  Be practical, now.  Try inventing a structured
programming language that provides automatic multiprocessor support, or
which implements parallel execution, or something.

Personally, I'm thinking of writing an IA64 assembler.  I'm sure that mine
won't come near to those currently being developed, but it will at least
teach me the instruction set.

Richard.



Wed, 06 Nov 2002 03:00:00 GMT  
 
 [ 23 post ]  Go to page: [1] [2]

 Relevant Pages 

1. C is NOT a portable assembler (was: want to know)

2. portable assembler and loader

3. Fantastic Smalltalk Contract California S. Davenport

4. SIGS is fantastic

5. Support - FANTASTIC

6. FANTASTIC OPPORTUNITY - WORLDWIDE APPARTMENTS

7. FANTASTIC OPPORTUNITY - WORLDWIDE APPARTMENTS

8. FANTASTIC OPPORTUNITY - WORLDWIDE APPARTMENTS

9. FANTASTIC OPPORTUNITY - WORLDWIDE APPARTMENTS

10. FANTASTIC OPPORTUNITY - WORLDWIDE APPARTMENTS

11. FANTASTIC OPPORTUNITY - WORLDWIDE APPARTMENTS

12. A fantastic book but now I want more.....

 

 
Powered by phpBB® Forum Software