Home > Archive > Compilers > August 2004 > generic assembly language available?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
generic assembly language available?
|
|
| ChokSheak Lau 2004-07-13, 4:01 pm |
| Hi all,
I get a feeling that gcc RTL seems to be the most generic kind of
intermediate code that exists today. I am interested in playing with
some kind of generic assembly language, or writing it, so that when we
write a compiler to target that language, the code generator will take
care of the rest. The thing about RTL is that it is not very human
friendly, like real asm code.
The closest analogy to what I am talking about is the Parrot language,
which is the interpreter engine for Perl 6. of cos, that could not be
easily converted into machine code because it was not designed to do
that.
My guess is that no such generic assembly language exists today.
Please email me to let me know I'm wrong. Thanks.
chok
| |
| Basile Starynkevitch [news] 2004-07-14, 3:57 am |
| Le 13-07-2004, ChokSheak Lau <choksheak@yahoo.com> a écrit_:
> Hi all,
>
> I get a feeling that gcc RTL seems to be the most generic kind of
> intermediate code that exists today. I am interested in playing with
> some kind of generic assembly language, or writing it, so that when we
> write a compiler to target that language, the code generator will take
> care of the rest. The thing about RTL is that it is not very human
> friendly, like real asm code. [...]
You should look into C--, see www.cminusminus.org for more.
If you want to generate quickly machine code, you might also consider
GNU lightning or libjit.
http://savannah.gnu.org/projects/lightning
http://www.southern-storm.com.au/libjit.html
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France
| |
| Gopi Bulusu 2004-07-14, 4:01 pm |
| > My guess is that no such generic assembly language exists today.
> Please email me to let me know I'm wrong. Thanks.
Depends on what qualifies as generic assembly language. Most compilers
emit intermediate code that is then processed by a code generator to
create the final assembly code for a specific processor.
If we defined generic assembly language as a human readable
intermediate code, I believe there will still be many languages out
there.
One of our research projects uses a very high-level intermediate code
that is both intuitive for humans to use and can be processed by a
code generator to generate the final assembly code for a particular
processor.
Some more information is available here:
http://www.sankhya.com/info/products/tools/dttf.html
Thanks,
gopi
---
Gopi Kumar Bulusu
Sankhya Technologies Private Limited
http://www.sankhya.com
Tel: +91 891 554 2666
Fax: +91 891 554 2665
[There have been some attempts at standards for assembly language like
IEEE 694-1985 twenty years ago. But I don't see any way to abstract
out the differences in the underlying machines short of putting a code
generator into the assembler which kind of defeats the purpose. -John]
| |
| ChokSheak Lau 2004-07-14, 4:01 pm |
| hi Gopi,
I think what you have is the closest to what I am looking for
(except it is not freeware), anyway, i am not sure whether the
idea of having a generic low-level language (much much lower
than C) is possible at all or not.
chok
"Gopi Bulusu" <gopi@sankhya.com> wrote in message
>
> Depends on what qualifies as generic assembly language. Most compilers
> emit intermediate code that is then processed by a code generator to
> create the final assembly code for a specific processor.
>
> If we defined generic assembly language as a human readable
> intermediate code, I believe there will still be many languages out
> there.
>
> One of our research projects uses a very high-level intermediate code
> that is both intuitive for humans to use and can be processed by a
> code generator to generate the final assembly code for a particular
> processor.
>
> Some more information is available here:
>
> http://www.sankhya.com/info/products/tools/dttf.html
[See if you can find info about LIL, a little low level implementation
language built at Bell Labs in the 1970s. It worked fine, but they
found that anything it could do, C could do just as well so there was
no point. -John]
| |
| Aharon Robbins 2004-07-15, 9:01 pm |
| ChokSheak Lau <choksheak@yahoo.com> wrote:
>I think what you have is the closest to what I am looking for
>(except it is not freeware), anyway, i am not sure whether the
>idea of having a generic low-level language (much much lower
>than C) is possible at all or not.
>
>chok
> [ .... ]
>
>[See if you can find info about LIL, a little low level implementation
>language built at Bell Labs in the 1970s. It worked fine, but they
>found that anything it could do, C could do just as well so there was
>no point. -John]
Norman Ramsey, I believe, is working on something called C-- which is
a low level language intended to be targeted by compilers...
HTH,
Arnold
--
Aharon (Arnold) Robbins --- Pioneer Consulting Ltd. arnold AT skeeve DOT com
P.O. Box 354 Home Phone: +972 8 979-0381 Fax: +1 530 688 5518
Nof Ayalon Cell Phone: +972 50 729-7545
D.N. Shimshon 99785 ISRAEL
| |
| Phil Budne 2004-07-15, 9:01 pm |
| >[See if you can find info about LIL, a little low level implementation
>language built at Bell Labs in the 1970s. It worked fine, but they
>found that anything it could do, C could do just as well so there was
>no point. -John]
I have a web page devoted to LIL; PJP graciosly supplied copies of a
paper and two BTL memos (which DMR helped provide clearance to release);
http://www.ultimate.com/phil/lil/
| |
| Gergely Buday 2004-07-17, 8:58 pm |
| "ChokSheak Lau" <choksheak@yahoo.com> wrote:
>
> I think what you have is the closest to what I am looking for
> (except it is not freeware), anyway, i am not sure whether the
> idea of having a generic low-level language (much much lower
> than C) is possible at all or not.
MLRISC also might be of interest:
http://cs1.cs.nyu.edu/leunga/www/ML...html/index.html
- Gergely
| |
| Ray Dillinger 2004-08-09, 3:56 am |
| ChokSheak Lau wrote:
> I think what you have is the closest to what I am looking for
> (except it is not freeware), anyway, i am not sure whether the
> idea of having a generic low-level language (much much lower
> than C) is possible at all or not.
For what it's worth, there is no problem with using C as a misspelled
assembly language. Since C is semantically similar to a superset of
assemby, you can have just about any feature you'd want in a "generic
assembly language" just by deciding which features of C you will not
use.
I did this a couple of years ago for a LISP compiler that emitted C
code; the code it emitted used goto's and handled its stack
explicitly. It used no C procedure calls or other C-stack based
control structures and it was effectively a generic assembly language.
Bear
[Lots of languages use C as a portable low-level back end. -John]
| |
| jacob navia 2004-08-23, 4:02 pm |
| Ray Dillinger wrote:
> ChokSheak Lau wrote:
>
>
>
> For what it's worth, there is no problem with using C as a misspelled
> assembly language. Since C is semantically similar to a superset of
> assemby, you can have just about any feature you'd want in a "generic
> assembly language" just by deciding which features of C you will not
> use.
>
> I did this a couple of years ago for a LISP compiler that emitted C
> code; the code it emitted used goto's and handled its stack
> explicitly. It used no C procedure calls or other C-stack based
> control structures and it was effectively a generic assembly language.
>
> Bear
> [Lots of languages use C as a portable low-level back end. -John]
I would say that an assembler that doesn't know about overflow is
lacking some features... :-)
I added this missing feature to lcc-win32, a "portable assembler" for
many languages (Eiffel, objective C, Heron, C++ and maybe others)
All in all I think C should introduce this feture:
a*=b;
if (_overflow())
// overflow handling.
In x86 machines, intrinsic functions that get translated to
single machine instructions are handy, like _rdtsc() that will
return a 64 bit integer with the cycles of the processor, or others
| |
| Julian Brown 2004-08-25, 3:59 pm |
| On 2004-08-23, jacob navia <jacob@jacob.remcomp.fr> wrote:
>
> I would say that an assembler that doesn't know about overflow is
> lacking some features... :-)
>
> I added this missing feature to lcc-win32, a "portable assembler" for
> many languages (Eiffel, objective C, Heron, C++ and maybe others)
>
> All in all I think C should introduce this feture:
>
> a*=b;
> if (_overflow())
> // overflow handling.
This worried me when I saw it before, I seem to remember, and it worries
me even more now. How can you be sure which operation you are testing
overflow from? With that syntax, you can't, especially not with an
optimising compiler. Is code ever inserted to make sure the operation is
"safe"?
What does this do:
a = b+c+d;
if (_overflow())
// something
If (a) the first, (b) the second + operator causes an overflow? For that
matter, which addition is the first?
Overflow handling shouldn't be added to C in this way, since not all
processors look like x86s with condition-code flags which are
calculated unconditionally, etc.
I do quite like the idea of being able to test overflow, though I
can't think of a sensible C-like syntax for it. Some processors, eg
SH4, must know ahead-of-time whether overflow (or carry) should be
calculated or not, since then different instructions should be used
(addv, afaicr).
A better solution (thinking on my feet) might be a special built-in
type for overflow- and carry-augmented integers and overloaded
operators to go with them:
oint a, b, c;
c = a+b;
if (c.overflow)
// something
This could probably even be done already (more or less) with inline asm
& C++.
Cheers,
Julian
|
|
|
|
|