Re: Architectural support for programming languages

Mayank Kaushik wrote:
Im a student of computer architecture, and ive often heard about
microarchitectural support in processors for operating systems to make
their life easier,

I think it is more about the architectural support for the sort of
things that systems and applications programs (written in some
language) do more than it a case of trying to support languages
themselves. The language used will match the programs, the
programs will match the architecture and will match the
problems being solved.

Consider control apps that don't need floating point vs desktop
apps that do. If a language doesn't support floating point then it
is probably not the language that you will use to write an FP app,
nor will you be likely to choose a chip without FP hardware to
solve an FP problem. If you are designing a low cost, low power
control app that doesn't need FP you probably won't want to pay
for FP hardware. And you can choose a language that has FP
support if it doesn't get in the way.

When you look at a chip with FP ask yourself, did they add FP
hardware to the chip to support some programming language or
did they add it to the hardware to support a class of apps. I say
that languages like hardware support a certain class of apps.

But when a hardware manufacturer says they are targeting Unix
apps they are also saying C because Unix is in C. It is easy to
see why hardware gets the same features that some language
has to handle some class of apps. The choice of language, with
its features, is driven by apps just like choice of hardware and its
features. It helps everything when the language closely matches
the hardware and both should match the problem being solved.

When microprocessors hit the scene they were very primitive and
very different than mainframe computers. They just ran their own
assembly language and they didn't have the architectural features
to support much of what people were doing in Fortran and COBOL.
..
C came along designed to write an OS for a minicomputer. As
microcomputers evolved to the modern desktop computer they got
the features to run modern Unix and Windows software.
Hardware/software co-evolution. Hardware designers need to solve
the same problems that a programming language will solve but from
a different direction. Hardware is enhanced in the same direction as
the software is enhanced in an app direction.

for example the task state table (im not sure if
thats the correct name) in an x86 processor which makes context
switches between processes easier for an operating system.

Yes, somewhere between 4004 and 80286 people started using C
on that Intel x86 family line and long ago Intel announced that they
were adding architectural features to take their share of new market
dominated by C.

In an introductory class i also heard about processors being optimized
for particular languages. This has me confused, what would be a
microarchitectural feature that would make a, say, C compiler`s job
easier? and how would it not (possibly) be of much use to another
language? Additionally, would object oriented languages like C++ or
Java perform better with support in a microarchitecture? could you give
an example of any such support feature?

C can compile programs for small computers, but people generally don't
use it to compiler the software for all those small embedded systems.
People do use C to compile popular OS and popular big C compilers
for big microcomputers and some smaller micros.

On the first page of the GCC documentation are statements about
architectural features that are needed to port GCC reasonably. In
particular 32-bit, enough memory for GCC itself, perferably lots of
general purpose registers. Features for the sorts of applications not
unlike many of those written in GCC, memory managment and
protection, indexed addressing to get into stack frames, etc. etc.
But not all languages require the same things.

Forth was designed to write a different sort of application and
embedded OS and has fewer (micro)architectural needs. It only
needs a couple of stacks and a little memory. There are very tiny
Forth machines that have the microarchitectural features that Forth
needs and are in the class of machines smaller than those people
use with C. Forth hardware and software fits in smaller places than C.

Lisp needs lists and machines that had instruction sets that
matched the lisp primitives were providing architectural features
that would not be as directly useful in a C compiler. Lisp and
Prolog can map pretty easily and cleanly to some stack
architectures while C was designed with some other ideas in mind.

Of course you can write a Prolog or a Lisp or a Forth or a Java in C
and run them under and OS written in C and on architecture with all
the architectural support to do all that that needs. But most
embedded computers in the past have had architectural features to
support low power and low cost, not C. But with transistor sizes as
small as they are today pretty big computers can be pretty small,
but large and small will always be relative terms.

With all the effort to optimize hardware and optimize software, with
the high volume production performance/cost advantages, with
product dumping below cost and other factors in the marketplace
designs to support architectural features to support programming
languages that need only a subset of C or are different than C have
not found sizable niches except where the language used is simply
assembly language and matches the hardware exactly.

Is Occam and the Transputer an example of microarchitectural
support for a programming language, or a programming language
matching the architectural features on a microprocessor needed
to solve the problems of parallel program execution in a certain way?

Are the designers going to multi-core microarchitectures today
doing it because they are following the way it is modeled in some
particular programming language? They may indeed be influenced
by wanting to support legacy methods of operation in the library
files that their intended customers are already using. I think that
is another indirect way that architectural features are added to
designs to support what they expect the progrogramming language
that will likely be used will most likely want the hardware to support.

Backwards compatibiliy is defined by indentifying the important
things that the most common software and the most common
programming language did with the last generation of hardware.
The language uses the library that includes the definitions in the
BIOS that use different features in the hardware than the final
applications but we need to continue to support those features
to support the common use, the expected use by the BIOS
writers and compiler writers. It is another example of the effect
of language and practice producing feedback that influences
what architectural features are seen as needed.

Which x86 processors only support protected mode and the
newest most efficient instructions and what is their market
share? Is the idea that people have a software library that
demands certain architectural features unrelated to the use
of a programming language?

.

Relevant Pages

  • Re: How Tcl speaks for itself and how Tcl is not spoken for... (Drifting off-topic)
    ... They were some of the most powerful mainframes of their time. ... Try to sell any CPU nowadays that can't support C and see what happens. ... Isn't it more a matter that the optimal language for any system would be that which most closely reflects the underlying architecture, so that compiler abstractions need not be overly lossy? ... C makes some assumptions about your architecture that, if your architecture doesn't support it, complex C programs won't run. ...
    (comp.lang.tcl)
  • Re: various objects in my VB6 project - Calling IUnknown
    ... legacy support for EXEs is an order of scale beyond ... "Language Stability" enjoyably employs structure. ... But I'm not black and white on the matter of migration changes. ...
    (microsoft.public.vb.general.discussion)
  • exactly manufacture in front of Moammar Rasul Mohammed
    ... architecture now, won't need telegraphs later. ... interpret except for responsible parishs, ... mixs in support of it, ... Ahmed spreads the punch as it were hers and ...
    (sci.crypt)
  • Re: how is Haskell not robust?
    ... Haskell has not reached critical mass. ... have a thousand packages but still poor support for mainstream package ... If anyone would make money with the language or a compiler ...
    (comp.lang.functional)
  • Re: Why should I eschew prototype.js?
    ... Microsoft drives this market, whether people admit it or not. ... out next week and proclaimed "The only markup language we will support ... Furthermore, if any other attributes are present, IE will ignore the script block. ...
    (comp.lang.javascript)