Fantastic, portable assembler.
Alt
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).
@?name> // a mark" for jump
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;
....
@loop: // define constant of code pointer
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;
....
@loop
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
email: ?jona...@microtec.fr>
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
emailes:a...@card.kyiv.net, al...@cybercafe.com.ua
(better write to both,
it would made probability that I'll read at leas from one)
Want somebody create an implementation of such conception ?
Alt
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).
@<name> // a mark" for jump
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--------------------------------------
email: <jona...@microtec.fr>
Richard John Cavell
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.
- r.ca...@ugrad.unimelb.edu.au
Newsgroups - Please copy your replies to me via email. (Server problems).
Alt
> 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
>
>
> 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.
> privilege levels,
same.
> conditional moves,
Why not ?!
My "if endif" construction allow to do it.
> 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.
>
> optimising, etc) are out.
What optimizing do you mean ?
>
>
> 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.
>
>
> 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.
> 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.
>
> 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.
>
>
> --------------
> Richard Cavell
> Melbourne University Medical Student
> Debater, Chess Player, etc.
> - r.ca...@ugrad.unimelb.edu.au
>
> Newsgroups - Please copy your replies to me via email. (Server problems).
Ok. I'll.
Richard John Cavell
On Fri, 19 May 2000, Alt wrote:
> > 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.
> 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?
> > 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.
Michael Lee Finney
@cassius.its.unimelb.edu.au>, rjca...@student.unimelb.edu.au says...
> 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.
Alt
> In article <Pine.OSF.4.10.10005182047310.15184-100000
> @cassius.its.unimelb.edu.au>, rjca...@student.unimelb.edu.au says...
> > 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.
>
>
> 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).
>
But I do not see closer tool as such assembler :).
>
> 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.
> Can assignments be given to explicit registers?
No.
>
> 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" ?
>
> 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.
> 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.
> Can instructions
> be predicated or speculated as in the I64 architecture?
>
It's how ? :)
>
> 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.
>
> 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. :)
Alt
> On Fri, 19 May 2000, Alt wrote:
>
> > > 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.
>
>
> > 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 :)
>
> > > 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.
>
>
> 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.
> 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).
>
>
> 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.
>
> Richard.
Richard John Cavell
> 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.
> 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.
> 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.
> Do you assume little endian, big endian or something in between?
Like middle-endian? heh, heh.
> Can instructions be predicated or speculated as in the I64
> architecture?
Worry about FMOVcc and XLAT before you worry about speculation.
Richard.
Richard John Cavell
> 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.
Alt
> On Fri, 19 May 2000, Alt wrote:
>
> > 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.
>
Hm :)
Automatic multiprocessor support.
Is not an language task at all.
First task of programming language is a description of an algorithm.
Ofcourse language must provide it in most useful form.
Classic language is a Fortran and its extension named C.
(Yes, C is only extension of Fortran.)
It allow to describe algorithms quite well.
But ... there is a cases where form of description of Fortran
is not enough informative. :(
Some of then is describing of algorithms which should work at
few processors atones. (Parallel algorithms.)
There is a language Occam.
(I heard it could be compiled in .... !electric circuit!)
Also exist "parallel Fortran" ("parallel C" also).
Again about automatic paralleling.
I told here that "CodeMophing" (I spell it "CodeMorfing")
was my idea.
I thought that it could automatically break an algorithm to the
several parallel processes. But it was too difficult....
>
> 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.
P.S. Where you from ? Your kind of english sounds unusual. (My too. :)
Alt
> On Fri, 19 May 2000, Michael Lee Finney wrote:
>
> > 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
>
You forgot assemblers of 8080, PDP-7, PDP-11, MIR-1, MIR-2 :)
(MIR - Mashyna Inzhenernykh Raschetov (rus-"machine for engineering
calculations")
first computer for "users" made in Kyiv in 70-n years.)
:)
>
> 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.
>
It looks similar but in a true they a really differently !
(I guess you mean (MOS Technology's) MCS650? and (Motorola's) MC680? .)
>
> > 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.
>
> > 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.
>
In my "portable assembler" is mo registers at all.
Like no stack at all, also.
But there is instruction of calling functions and return from it.
Between I forgot to write (in description of assembler)
that "call" have parameters
Look:
call <name> (output variables) (input variables)
(where <name> - name of procedure which have type "pointer_code")
Perhaps stack operation might be added.
But there is different ways to relay parameters from/to function.
Some of them use stack other not, I hide such task from programmer
and stack operation could break variable relaying order.
Additional restrictions to using stack instruction could
disorientate programmer.
Two stacks is possible but stupid. :)
Simples decision hide stack at all. :)
Juzzer
> > P.S. Where you from ? Your kind of english sounds unusual. (My too. :)
>
>
> Richard Cavell.
>
Oh, that explains it, ha ha ha ! :-)
Juz in the Motherland (England)
Alt
> On Sat, 20 May 2000, Alt wrote:
>
> > Automatic multiprocessor support.
> > Is not an language task at all.
>
> Multithreading is really what multiprocessor support is all about, in
> practise. BeOS can supposedly use multiple processors on programs which
> aren't intrinsically designed to be multithreaded.
>
OS can not break entire program.
But it is able to distribute tasks between processors.
However ... entire program may use multiprocessor libraries, also.
But entire is entire parallel is parallel.
>
> > P.S. Where you from ? Your kind of english sounds unusual. (My too. :)
>
> I am a native English speaker,
^^^^^^^^^^^^^^^^^^^^^^^^^^ everybody say so. :)
> born in Melbourne, Australia.
... I would guess you have *.au domain.
Look english in England, Netherlands/Beligium, several states of USA.
Is quite different language.
Some programs even recognize engilsh/usa and english/uk like different.
>
>
> Richard Cavell.
Alt
> In article <392547E2...@card.kyiv.net>, a...@card.kyiv.net says...
> > Michael Lee Finney wrote:
> >
> > > 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 :).
>
> But it is what you have sort of implied by your answers to various
> questions.
>
> > > 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.
>
> If all registers are virtual then you have to define a conceptual set of
> registers (possibly unbounded in size). The assembler has to generate
> "spill" code which tends to interfere with use of the stack. There are
> algorithms which make heavy use of the stack -- but some machines don't
> have a stack and register spill code can make it very difficult to write
> such code. So you may have to give up any control over the stack.
whom for give up?
Hide it from the programmer.
Or allow to use it for programmer.
Or give up it at all ?
> That is
> where many assembler optimizations occur.
>
> > > 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" ?
>
> The term "endian" refers to the order in which the contents of a register
> are stored in memory. If a register has 4 bytes, there are 4! = 24
> possible byte orderings. Only some of those are common -- three, actually,
> with two most prevalent. If the value in the register is 0x12345678 then
> "little" endian will store bytes in the order: 0x78, 0x56, 0x34, 0x12 and
> "big" endian will store bytes in the order: 0x12, 0x34, 0x56, 0x78 and one
> of the "mixed" formats will store bytes in the order 0x34, 0x12, 0x78, 0x56
> but is not very common. In theory (given that you can't assume platform)
> virtually any of the 24 possible formats could occur. One problem with
> portable code is simply handling byte order.
>
> A simple case where it is significant. On platforms which has IEEE
> floating point, the most significant bit of the most significant byte
> contains the "sign" bit and to negate a number you simply need to flip that
> bit. Loading a floating point number, flipping the bit and storing the
> floating point number can be much slower that simply using a memory
> immediate instruction to flip the bit in memory. But, you have to know
> where the bit is located in memory and that means that byte order is
> significant to the algorithm. Not only that, but some machines don't have
> memory immediate instructions so if those are simulated the result could be
> slower than a "naive" approach.
>
> Since the purpose of writing in assembler is in, many cases, using
> algorithms such as the above, simulating memory immediate instructions may
> not be acceptable and even if that hurdle is overcome knowledge of byte
> order is very significant.
>
> A modification of the above appproach would be to load the floating point
> value into and integer register, flip the bit and save it. That may be
> desirable on machines which don't have memory immediate instructions but
> which have fast integer load/store times and slow floating point load/store
> times. Clearly, it may be desirable for that value to remain in a register
> for some span of time -- but assembler generated register spill code could
> mean that the benefits of the approach could be lost due to the extra loads
> and stores needed to handle virtual registers.
>
Br-r-r.
Could you write clearer in further ? :)
So, about the floating point. - I don't know how to apply it at all.
about an order of bits.
The highest bit is a sign bit. as signed type.
When you need access the some byte from the multy - byte variable,
(or two bytes in the much as two byte variable)
... perhaps it's need an extension variable like structure.
look:
....
byte4 a;
byte2 b;
byte c, d;
.....
mov b, a.high; high part of 4-byte data
mov c, b.low; or
mov c, b; or
mov c, (byte2)b.low; or
mov c, (byte)b; low part of two byte variable
mov d, a.3
Size of result defines by result variable,
size of source defines by such extension:
.low
.high
.<number of byte>
Perhaps there is a sense apply all of C-like data access / addressing
instruments.
>
> > > 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.
>
> No, the solution is not optimization. Generally algorithms are designed
> with those instructions in mind and the assembler can't read your mind and
> change the code just because extra instructions are available. For
> example, without some special language support, the MMX instructions would
> almost never be generated.
>
> And, yes, the problem does exist for C, Fortran and other languages. That
> is one of the main reasons that code is still written in assembler. The
> entire point of a portable assembler would be to allow such code to be
> generated. If an assembler could do it, so could C or Fortran, and then
> assembler wouldn't be needed in the first place.
>
I guess not at all.
There is too many kind of the optimization.
Optimization used not only for the machine code.
(remember (?) I asked "what optimization ?" )
Optimization used in the artificial intelligent, data bases,
CAD'es, and actually in the any data processing.
And in the rare case ideal optimization is possible,
in others optimizer only help to make a data in better
order as it (optimizer) get it (data).
And as much data is pre-optimized before to be entered in
the optimizer as better data optimized in the output.
... I mean in general.
Or may be I am wrong.
I need to ask this question somebody who know better as I do.
>
> > > 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.
>
> Some machines (especially older designs) only have a singe condition code
> regsiter. But there are machines with more than one condition code
> register which can be used in many different ways when writing code. You
> can, for example, hold partial results in the condition code registers and
> then directly perform logic on the condition code registers.
>
> Other machines don't have condition code registers at all. You have
> instructions that do a combined test and branch, but you can't store the
> results of a test and then branch later.
>
Aha,
yes you are right
but in a true conditional operations is from few percents
to less then one percent from the other operation .
And in most cases simple flags operations is enough.
Thank, that you point my attention here.
>
> > > Can instructions
> > > be predicated or speculated as in the I64 architecture?
>
> > It's how ? :)
>
> One of the approaches possible is that there are "predicate" registers
> which are a single bit. Then you can save the result of a test in a
> predicate register and other instructions can be executed conditionally
> based on the value of the predicate register. So, instead of writing code
> like....
>
> cmp a,b
> jmp lt,x
> mov c,d
> jmp y
> x: mov c,e
> y:
>
> you can write code like:
>
> {1,2} <- cmp a,b
> [1]mov c,d
> [2]mov c,e
>
> which avoids all kind of problems such as flushing the instruction cache
> and the delays involved in executing extra jmp instructions. Please note
> that neither code sequence above is intended to represent any particular
> "real" machine.
>
> But, when using predicated instructions you can do things that cannot be
> easily done without them. Since you simply make instructions conditional
> on a predicate register, those instructions can be moved around, they can
> be interleaved with other instructions and all kinds of optimizations can
> open up as a result which simply aren't possible without them.
>
> Predicated instructions are available on some machines and not on others.
> Some machines that have them, have them for most instruction and other
> machines only have them for a very limited set of instructions (such as the
> CMOV for the X86 platform).
>
> How do you handle differences like that? If you simply "hide" it all, then
> you are losing much of the advantange of an assembler and you really are
> writing something like C and not a portable assembler at all.
(!) between I forgot add compare instruction in project of
my syntax ;-J , :-)
Let it be
cmp <var>,<var>; result in C
Look
{
.....
cmp a,b
if C
mov d,c
endif
ifn C
mov e,c
endif
....
}
might be easy transformed (translated) in both of the your examples.
Don't you believe ?
Or may be I need to ad command (meta-instruction) "else" ?
Alt
> In article <Pine.OSF.4.10.10005201536250.2135-100000
> @cassius.its.unimelb.edu.au>, rjca...@student.unimelb.edu.au says...
> > On Fri, 19 May 2000, Michael Lee Finney wrote:
> >
> > > 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:
> >...<snip>...
> > Worry about FMOVcc and XLAT before you worry about speculation.
> >
> > Richard.
>
> I believe that you are mistaking my intent. I am pointing out the
> difficulty involved. Your points are more of the same (and perfectly
> valid). There are lots of issues that I haven't mentioned to the original
> poster.
>
> Nevertheless, to play Devil's Advocate, let us suppose that some
> simplifying assumptions are made, such as:
>
> 1. A registers will be virtual and unbounded in number. There will be
> different registers for each size of integer and for signed vs. unsigned,
> based on powers of 2 (this already excludes some very old machines). There
> would be separate pointer registers for each data type, including defined
> types. The floating point registers would assume IEEE floating point with
> the biggest issue to distinguish between 80, 96 and 128 bit extended double
> precision formats (nobody provides extended single precision formats, so
> far as I know). Appropriate transfers between registers will be provided.
>
I assumed that will be no registers, variables only,
with a fixed size (declares in the variable declaration),
but without a fixed type
"byte2" - might be a signed, a unsigned or a decimal, but with a length
in two bytes.
Only a "pointer_code" and a "pointer_data" have defined types
because in different machines it have different size.
Mean (type) of the data variables defined by operations which applied to it.
Look:
int one (int a, b)
{
return(a+b);
}
and
unsigned int two (unsigned a, b)
{
return(a+b);
}
- have no difference in assembler.
Difference exist only in that cases
when assumed signed data from registers
with a different number of bits.
In such case sign correction required.
Between seems that I forgot made a instruction for it.
(Not every instruction set contain it.)
>
> 2. The stack will be entirely controlled by the assembler, so no direct
> stack operations will be provided.
Yes.
There is a sense to add the stack operations, with an ugly restrictions.
>
>
> 3. No privileged instructions will be provided. No control of the cache,
> paging, privilege levels, etc.. This is properly the domain of the
> operating system and presumably not the target of such a portable
> assembler.
>
Yes.
>
> 4. All of the common logical and arithmetic operations will be provided.
> These are available on essentially all machines.
>
Yes.
>
> 5. All of the approaches to conditions will be provided: "combined test and
> jump", "test and jump based on condition codes" and "condition code
> registers". Even simple control structures could be provided to maximize
> the effectiveness of translating to individual machine architectures.
>
No.
Only through "if" "ifn" "endif" and may be "else" operators will be provide
conditional branches.
Might be you don't believe :),
but it easy translatable to native "branching instruction" of every processor.
>
> 6. Loading and storing values will always be done through a pointer
> register. Loading explicit constants will be allowed and will also be
> allowed in the logical and arithmetic constants. Using a pointer in
> logical and arithmetic operations will also be allowed. Some indirect
> operations might be provided which are especially useful (such as indirect
> jump or call).
>
No all values stored in the variable.
Only translator defined which variable will be in memory (and where)
and which in a register.
Of course variable, which from pointer was taken, must be in memory.
But in most cases when we left a task of swapping between
the memory and the registers for the translator there is no sense
address variable though pointer, except access to the structures and areas.
... what about the index registers ?? 8-?
I have to review the conception of variables ... and add there an indexing...
>
> 7. Some "speciality" instructions could be provided that are available on
> some platforms and not others (such as leading/trailing bit detection) but
> which can be especially useful. This could be where MMX type of
> instructions would be placed. Alternatively, some sort of parallel array
> logical and arithmetic registers could be used.
Yes,
as extension.
>
>
> There are other issues, but just given the above, something useful could be
> done. In fact, such an approach would look quite a lot like an
> intermediate compiler representation -- not surprising since such
> representations have to deal with exactly the same issues. However, it
> would be (in my opinion) useful and lower level than C. As such it could
> be called a "portable" assembly language. It could also be considered an
> assembly language for a "hypothetical" machine in the same vein as MIX.
>
> None of the above decisions fit any machine perfectly. However, the
> instructions provided would largely all have extremely simple translations
> for most modern processors. In some cases two or more target machine
> instructions might be needed (loading a constant, for example). Details
> such as assignment to physical registers, spill points and loading parallel
> pipelines are extremely machine dependent and presumably here there would
> be at most "hints" from the programmer and the assembler would take care of
> those points.
>
....
>
> Stuffing the pipes and things like that is one of the areas that the
> compiler can almost always do better than the programmer (please note the
> "almost always"). I have written C++ code, compiled it, extracted it to an
> assembler and attempted to improve it -- and found that I never got more
> than a 10% improvement and that was extremely "iffy". The best improvement
> I made was minor changes to the algorithm which allowed the compiler to
> eliminate delays and pipe conflicts. Modern compilers are extremely good
> for short sequences of code, it is over larger sequences they lose
> effectiveness and for global decisions.
>
Yes.
>
> It is a fine line here between calling such a thing a "computer language"
> or a "portable assembler". I favor the latter because it does explicitly
> emphasis things such as registers and tries to adhere fairly closely to
> instruction sets instead of expressions. For the same reasons, I would not
> call C a portable assembler even though many others have done so. It is
> merely a low-level procedural language -- and not all that "low-level".
>
> This approach to a portable assembler would still allow the programmer to
> exercise of the creativity involved, and with some hinting could still
> attempt to influence things such as register assignment where sometimes a
> programmer's knowledge gives better results than canned algorithms.
>
> I think the usefulness would be determined by the details. Assembly
> languages for hypothetical machines such as MIX have served well to
> illustrate algorithms. Intermediate compiler representations similar to
> the above (but more machine oriented) have served well for writing
> compilers which work on multiple platforms. In both cases, what is
> included is restricted and no attempt is made to model the entire machine.
> I think that is the key here -- isolate the commonalities, provide a
> simplified view of the machine and provide simple emulation where a
> platform does not have support for some concept.
Under "Emulation" you mean "interpretation", isn't it ?
If so, I like to tell you that I do not see fast border between
interpretation and compilation, actually any
modern binary file contain elements of interpretation.
Especially with C++.
>
>
> It could be done. How useful it would be would depend on the precise
> design decisions made.
>
>
> I would be interested in such a project, but don't really have the time to
> devote to it at this time.
You helped in something yet .
Alt
> On Sat, 20 May 2000, Michael Lee Finney wrote:
>
> > I believe that you are mistaking my intent. I am pointing out the
> > difficulty involved.
>
> Yes, I realise I sounded like I was arguing against you, but I'm not.
>
> > 1. A registers will be virtual and unbounded in number.
>
> Then they're not registers, they're local variables which can be optimised
> as true register variables at the assembler's discretion. Just like C++
> register int x;
>
> > 2. The stack will be entirely controlled by the assembler, so no direct
> > stack operations will be provided.
>
> So you can't access parameters/arguments (which are usually provided on
> the stack). The assembler would then only be able to compile entire
> programs, and not subroutines which can be linked to C/C++ programs.
Why not ? 8-( ]]]]
There was a single task for such conception of the portable assembler.
"portable assembler" support relay of parameters through prototype of function.
And how it would be done dependent by concrete platform.
>
>
> > 5. All of the approaches to conditions will be provided: "combined test and
> > jump", "test and jump based on condition codes" and "condition code
> > registers". Even simple control structures could be provided to maximize
> > the effectiveness of translating to individual machine architectures.
>
> And all of these functions are poor form on the IA64, and ought to be
> optimised away.
>
"if" "ifn" "endif" nothing else.
>
> > 6. Loading and storing values will always be done through a pointer
> > register.
>
> So global variables, like :
>
> x: declare 4-byte integer stored here;
> move eax, x;
>
> Will not compile.
>
There must be a ... vision areas of variables (though indexing).
And must be a ways of addressing different from current vision areas,
in hierarchical and random orders...
>
> > allowed in the logical and arithmetic constants. Using a pointer in
> > logical and arithmetic operations will also be allowed.
>
> Are you going to allow pointer misalignment? Acceptable (though not
> advisable) on x86 but not on other systems.
>
What ? 8-0
>
> > There are other issues, but just given the above, something useful could be
> > done. In fact, such an approach would look quite a lot like an
> > intermediate compiler representation
>
> I think so. I think any attempt to make a portable assembler will end up
> looking like C with a different syntax. As far as I can tell, assembly, C
> and C++ were all revolutionary when they were introduced, because they
> provided in turn symbolic programming, structured programming and
> object-oriented programming. Since then I haven't seen any programming
> language which wasn't just a reworking of one of those three ideas.
>
> > assembly language for a "hypothetical" machine in the same vein as MIX.
>
> Or Java bytecode?
>
No, Java is absolutely different.
May be p-assm have a close goals.
>
> > It is a fine line here between calling such a thing a "computer language"
> > or a "portable assembler". I favor the latter because it does explicitly
> > emphasis things such as registers
>
> but your registers are just hints at the assembler - the same way that I
> can write
>
> for (register int x=0; x<10;x++)
> do something;
>
> and the 'register' may or may not be applied.
>
Yes.
>
> > I would be interested in such a project, but don't really have the time to
> > devote to it at this time.
>
> Well, as I said, I don't think it will work but if someone were to start
> work I'd be prepared to look over it and contribute something.
>
Thank you for it also.
>
> Richard.