Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #2040

Language standards vs. implementation, was Re: A right alternative to IEEE-754's format

Show all headers | View raw

 [[ this string is copied from comp.arch because your moderation found it interesting ]]

On 2018-04-09 10:29 AM, MitchAlsup wrote:
 > On Monday, April 9, 2018 at 6:30:35 AM UTC-5, Walter Banks wrote:
 >> In my experience there are a lot of ISA's designed for machine
 >> generated code that don't map very well in the GCC (some do as
 >> well) A processor that I have been working on for example it is
 >> essentially impossible to write an assembler for.
 >
 > To write an assembler, or to write IN assembler.
 >
 > I worked on a machine that it was even hard to read assembler.
 > Multiple instructions were grouped together and executed as if
 > atomically. Then all of the resource requirements were hoisted to a
 > header of the group so the HW scheduler could make the execute/wait
 > decision more easily.

I have seen both as issues in ISA's. The eTPU co-processor has many code
generation restrictions that need to be part of the tool set. What I did
in that one was actually generate the intermediate code format in the
compiler to take advantage of the compiler generated code error checking
and instruction building operations for three running threads in the
ISA. This instruction set is now close to 20 years old. I Only know of
two applications using assembler in the eTPU out of several thousand
written in C.

The processor I am thinking that is close to be release essentially has
no clean way to describe the ISA operations that are meaningful to
describe application code operations. In combination with that are
generation timing and code organization requirements. The ISA is
organized around things that computers do well and hand coding not so much.

 >>
 >> GCC tools are for the most part using old compiler technology. Some
 >> of is decades old.
 >
 > But has there been any real advances since Oho and Ullman came out?

The short answer is yes. Most are around getting away from limits on
compiler host processors, having a bigger picture of the application
code and how to handle more details on the ISA in the compiler. The
basic parsing and language processing is the same. As an example,
doing data and control flow analysis earlier rather than later in
the compiling process makes a big difference in generated code.

w..

Back to comp.compilers | Previous | Next | Find similar

Thread

Language standards vs. implementation, was Re: A right alternative to IEEE-754's format "Walter Banks" <walter@bytecraft.com> - 2018-04-10 11:06 -0400

csiph-web