Fantastic, portable assembler. 
Author Message
 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.

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....

Quote:

> 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. :)


Wed, 06 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

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.)
:)

Quote:

> 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? .)

- Show quoted text -

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.

> > 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. :)



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

Quote:
> > P.S. Where you from ? Your kind of english sounds unusual. (My too. :)

> I am a native English speaker, born in Melbourne, Australia.

> Richard Cavell.

Oh, that explains it, ha ha ha !   :-)

Juz in the Motherland (England)



Thu, 07 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.

Quote:


> > 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.

Quote:

> > P.S. Where you from ? Your kind of english sounds unusual. (My too. :)

> I am a native English speaker,

  ^^^^^^^^^^^^^^^^^^^^^^^^^^ everybody say so. :)

Quote:
> 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.
Quote:

> Richard Cavell.



Fri, 08 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.

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 :).

> 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 ?

- Show quoted text -

Quote:
>  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.

- Show quoted text -

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.

> 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.

- Show quoted text -

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.

> 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.

- Show quoted text -

Quote:

> > >  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
....

Quote:
}

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" ?



Sun, 10 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.

Quote:

> In article <Pine.OSF.4.10.10005201536250.2135-100000


> > > 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);

Quote:
}

and

unsigned int two (unsigned a, b)
{
return(a+b);

Quote:
}

- 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.)

Quote:

> 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.

Quote:

> 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.

Quote:

> 4. All of the common logical and arithmetic operations will be provided.
> These are available on essentially all machines.

Yes.

Quote:

> 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.

Quote:

> 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...

Quote:

> 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.

- Show quoted text -

Quote:

> 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.

....

Quote:

> 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.

- Show quoted text -

Quote:

> 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++.

Quote:

> 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 .


Sun, 10 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.

Quote:


> > 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.

Quote:

> > 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.

Quote:

> > 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...

Quote:

> > 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

- Show quoted text -

Quote:

> > 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.

Quote:

> > 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.

Quote:

> > 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.

- Show quoted text -

Quote:

> Richard.



Sun, 10 Nov 2002 03:00:00 GMT  
 Fantastic, portable assembler.
BTW, those who are interested in
"portable assembly" should take a look
at the two "C--" projects floating around.
These projects, while not true portable
assemblers in the sense discussed in
this thread, attempt to provide a portable
code generator for compiler output
(for compilers that generate C code
rather than assembly code).
Randy Hyde


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

 Relevant Pages 
 

 
Powered by phpBB® Forum Software