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

Groups > comp.arch > #2522 > unrolled thread

Joint Design of Instruction Set and Language

Back to article view | Back to comp.arch

Contents

  Joint Design of Instruction Set and Language jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) - 2011-07-15 00:24 +0000
    Re: Joint Design of Instruction Set and Language nmm1@cam.ac.uk - 2011-07-15 08:36 +0100
      Re: Joint Design of Instruction Set and Language Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-07-15 18:05 +0100
    Re: Joint Design of Instruction Set and Language anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-15 08:14 +0000
      Re: Joint Design of Instruction Set and Language John Levine <johnl@iecc.com> - 2011-07-15 10:32 +0000
        Re: Joint Design of Instruction Set and Language Anne & Lynn Wheeler <lynn@garlic.com> - 2011-07-15 10:18 -0400
        Re: Joint Design of Instruction Set and Language anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-15 16:30 +0000
          Re: Joint Design of Instruction Set and Language Anne & Lynn Wheeler <lynn@garlic.com> - 2011-07-15 14:26 -0400
      Re: Joint Design of Instruction Set and Language torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-07-15 14:26 +0200
        Re: Joint Design of Instruction Set and Language Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-07-15 15:59 +0200
      Re: Joint Design of Instruction Set and Language jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) - 2011-07-15 13:48 +0000

#2522 — Joint Design of Instruction Set and Language

My attempts to reply to the original post are failures, perhaps because
of a semicolon in the list of groups, even after I edit it out.

Roberto Waltman wrote:
> My short list:
>    Lilith + Modula-2
>    LISP machines + LISP, of course
>    Burroughs B5000 + Algol's
>    The various Forth processors,
>    Transputers + Occam,
>    Xerox Alto?

There was an experimental project at IBM that involved running a 360/30
with custom microcode to implement APL more efficiently.

Western Digital made the Pascal MicroEngine, which directly ran the
P-code for UCSD Pascal.

I'm not sure if the KDF 9 and Algol would really count.

Peter Flass wrote:
>IBM 5100: APL.

Sorry, no.

The IBM 5100 used a nanocode language in which to implement a microcode
interpreter. Then it used microcode to interpret a subset of the IBM 360
machine language to run APL - using VS/APL. So the machine language was
not designed around APL.

John Savard
http://www.quadibloc.com/index.html

[toc] | [next] | [standalone]

#2527

In article <4e1f887a.16587593@news.aioe.org>,
John Savard <jsavard@excxn.aNOSPAMb.cdn.invalid> wrote:
>
>I'm not sure if the KDF 9 and Algol would really count.

Not really.  Algol was its main one, not its only or intrinsic one.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#2541

On 15/07/2011 08:36, in article ivoqm9$e0r$1@gosset.csi.cam.ac.uk,
"nmm1@cam.ac.uk" <nmm1@cam.ac.uk> wrote:

> In article <4e1f887a.16587593@news.aioe.org>,
> John Savard <jsavard@excxn.aNOSPAMb.cdn.invalid> wrote:
>> 
>> I'm not sure if the KDF 9 and Algol would really count.
> 
> Not really.  Algol was its main one, not its only or intrinsic one.

The KDF9's Algol compilers were afterthoughts (but happy ones).  Work on
them did not begin until some time after the h/w architecture of the KDF9
had been published.  KDF9 was really designed to be a superb assembly
language machine, and succeeded in that.  Its Algol systems, though very
influential, were less than a triumph.

-- 
Bill Findlay
<http://www.findlayw.plus.com/KDF9/#Walgol>

[toc] | [prev] | [next] | [standalone]

#2529

jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
>My attempts to reply to the original post are failures, perhaps because
>of a semicolon in the list of groups, even after I edit it out.
>
>Roberto Waltman wrote:
>> My short list:
>>    Lilith + Modula-2
>>    LISP machines + LISP, of course
>>    Burroughs B5000 + Algol's
>>    The various Forth processors,
>>    Transputers + Occam,
>>    Xerox Alto?

I can only guess what this is about, but here are some more, in the
context of RISC processors:

SPUR + LISP
SOAR + Smalltalk (I highly recommend David Ungar's PhD thesis)

Then there are hardware approaches for executung Java VM code; at
least one from Sun (which didn't fly AFAIK), and the Jazelle mode for
the ARM architecture (not sure how significant that is; it was
deemphasized in ARMv7).

One other I remember is:

Hobbit+C

In some sense many RISCs are C processors (or maybe Pascal), because
the benchmarks they were tuned for were written in C or Pascal, but of
course the idea here is quite different than in Hobbit or Waltman's
short list, with more sophiticated compilers instead of hardware
"closing the semantic gap".  Still, the results of comparison
instructions in MIPS and Alpha, and some of the string instructions on
Alpha are definitely designed for C (a RISC designed for, e.g., Forth
would have looked differently).  Power has a FORTRANish flavour,
though:-).

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

[toc] | [prev] | [next] | [standalone]

#2531

>In some sense many RISCs are C processors (or maybe Pascal), ...

The Berkeley RISC and the SPARC were, in practice if not in theory,
designed around the PCC C compiler.  The reason they used register
windows was that PCC wasn't smart enough to minimize register saves.
The IBM 801, designed at the same time with the much more advanced
PL.8 compiler had a normal register set and load/store multiple
since the compiler was able to minimize the number of registers
to store.

R's,
John

[toc] | [prev] | [next] | [standalone]

#2538

John Levine <johnl@iecc.com> writes:
> The Berkeley RISC and the SPARC were, in practice if not in theory,
> designed around the PCC C compiler.  The reason they used register
> windows was that PCC wasn't smart enough to minimize register saves.
> The IBM 801, designed at the same time with the much more advanced
> PL.8 compiler had a normal register set and load/store multiple
> since the compiler was able to minimize the number of registers
> to store.

I've commented that John did 801 in re-action to hardware complexity of
the (failed) FS effort
http://www.garlic.com/~lynn/subtopic.html#futuresys

at presention in '76, the 801 group claimed that the hardware
simplification would be traded off against the sophistication of cp.r
operating system and pl.8 compiler.

no hardware domain protection would be compensated by pl.8 compiler only
generating correct code, and cp.r operating system only loading correct
programs. the few number of virtual address segment registers would be
compensated by inline application being able to switch virtual address
segment registers ... as easily as general purpose (address) register
values, can be switched. 801 would also not have any cache consistency
(since 370 & FS had very high penalty for cache consistency).

circa 1980, there was big internal push for migrate large number of
internal microproceessors to 801 (Iliad) ... including lots of
controller microprocessors and the microprocessors used in low-end and
mid-range 370 (aka followon to 4341, the 4381 was originally to be
801/iliad processor). misc. old email mentioning 801, risc, iliad, etc
http://www.garlic.com/~lynn/lhwemail.html#801

when most of those efforts failed, some number of engineers left to do
risc efforts at other companies.

the 801/ROMP was originally going to be for the follow-on to the
displaywriter ... when that effort failed, they looked around and
decided on retargeting for the unix workstation market. as part of that,
the company that had done the AT&T port for pc/ix, was contracted to do
a AT&T port to romp (becoming aixv2). hardware protection domain was
also needed in romp for transition from cp.r to unix. misc. past posts
mentioning 801, risc, romp, rios, power, power/pc, etc
http://www.garlic.com/~lynn/subtopic.html#801

for fun of it ... old email about request for 801 by LISP machine group:
http://www.garlic.com/~lynn/2003e.html#email790711
in this post (with several other old 801 emails)
http://www.garlic.com/~lyynn/2003e.html#65 801

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#2540

John Levine <johnl@iecc.com> writes:
>>In some sense many RISCs are C processors (or maybe Pascal), ...
>
>The Berkeley RISC and the SPARC were, in practice if not in theory,
>designed around the PCC C compiler.  The reason they used register
>windows was that PCC wasn't smart enough to minimize register saves.
>The IBM 801, designed at the same time with the much more advanced
>PL.8 compiler had a normal register set and load/store multiple
>since the compiler was able to minimize the number of registers
>to store.

And IA-64, which was designed for extremely sophisticated compiler
technology, has the register stack, which is a more flexible version
of register windows.  Register windows may not help much in SPEC CPU,
but programs that are actually used are compiled with separate
compilation, use dynamic linking and indirect calls (e.g., virtual
function calls), and even sophisticated compilers are quite limited in
their register allocation capabilities under these circumstances.

Of course, if you cannot get a competetive clock rate and IPC for the
resulting hardware, the register stack/windows won't save you.

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

[toc] | [prev] | [next] | [standalone]

#2543

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> And IA-64, which was designed for extremely sophisticated compiler
> technology, has the register stack, which is a more flexible version
> of register windows.  Register windows may not help much in SPEC CPU,
> but programs that are actually used are compiled with separate
> compilation, use dynamic linking and indirect calls (e.g., virtual
> function calls), and even sophisticated compilers are quite limited in
> their register allocation capabilities under these circumstances.

re:
http://www.garlic.com/~lynn/2011i#56 Joint Design of Instruction Set and Language

with regard to engineers leaving for other companies after various
internal 801 efforts were canceled

... a couple old emails regarding people leaving (and asking if i
would go also)
http://www.garlic.com/~lynn/2003e.html#email811006
http://www.garlic.com/~lynn/2003e.html#email811006b
in this previously referenced post
http://www.garlic.com/~lynn/2003e.html#65 801

itanium wiki
http://en.wikipedia.org/wiki/Itanium

one of the people is (also) credited with retrofitting "access
registers" to 3033 as dual-address space, doing a lot of 801 stuff then
leaving and doing risk for another vendor ... and then of the main
people behind wide-word and i64. misc. past posts:
http://www.garlic.com/~lynn/2000c.html#84 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2002g.html#18 Black magic in POWER5
http://www.garlic.com/~lynn/2004f.html#28 [Meta] Marketplace argument
http://www.garlic.com/~lynn/2004f.html#29 [Meta] Marketplace argument
http://www.garlic.com/~lynn/2006.html#39 What happens if CR's are directly changed?
http://www.garlic.com/~lynn/2006e.html#1 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006o.html#67 How the Pentium Fell Short of a 360/195
http://www.garlic.com/~lynn/2008g.html#60 Different Implementations of VLIW
http://www.garlic.com/~lynn/2009p.html#6 Is it time to stop research in Computer Architecture ?
http://www.garlic.com/~lynn/2010h.html#2 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010h.html#10 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2011f.html#17 New job for mainframes: Cloud platform

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#2533

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:


> In some sense many RISCs are C processors (or maybe Pascal), because
> the benchmarks they were tuned for were written in C or Pascal,

Benchmarks are still largely written in C, so you could say that nearly
all modern processors are, if not designed for C, at least tuned for
maximum C performance.  Even media ISA extensions, though mostly
programmed in assembler, are mainly intended for writing libraries that
make C benchmarks (such as media decoders) run faster.

More importantly, design decision that may potentially hurt C
performance are never made, even if they might benefit implementations
of other languages.  And features that are difficult to use from C but
may benefit other languages have low priority.

For example, few processors designed after 1990 have good support for
multiprecision integer arithmetic (such as carry flags, NxN->2N
multipliers and integer divison instructions that also provide
remainder).

Similarly, the vendor-mandated procedure call standards are also highly
C specific: No standardised way of handling exceptions, multiple
function results, tail calls, GC etc., as these are not interesting for
C.

	Torben

[toc] | [prev] | [next] | [standalone]

#2536

Torben Ægidius Mogensen wrote:
> More importantly, design decision that may potentially hurt C
> performance are never made, even if they might benefit implementations
> of other languages.  And features that are difficult to use from C but
> may benefit other languages have low priority.

True.
>
> For example, few processors designed after 1990 have good support for
> multiprecision integer arithmetic (such as carry flags, NxN->2N
> multipliers and integer divison instructions that also provide
> remainder).

In the case of x86-style 2N/N ->(N,N) DIV, I've come to the conclusion 
that it is rarely worthwhile, except for very small bignum code, i.e. 
when implementing 2N to 4N bit operations using N-bit code.

As soon as we get into arbitrary precision reciprocal-based code is 
almost always a win, with an asymptotic cost of about 3 muls, right?

If we work with 256 to 1024-bit integers, where it would be natural to 
chain a number of doublewide DIVs, we can instead use 1-2 NR iterations 
to get a good approximation to a reciprocal, then use mul/back-mul/sub 
and adjust.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[toc] | [prev] | [next] | [standalone]

#2534

On Fri, 15 Jul 2011 08:14:07 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote, in part:

>I can only guess what this is about,

There's a posting entitled

Architecture / Instruction Set / Language co-design

by Roberto Walkman, and that posting and the thread deriving from it is
in comp.arch, alt.folklore.computers, and comp.compilers.

It is visible in Google Groups.

However, attempts to reply to this thread from Google Groups fail,
probably because the list of groups is defective; it is:

comp.arch, comp.compilers;, alt.folklore.computers

with a semicolon AND a comma following comp.compilers.

As a result, except for some replies to the thread where headers are
trimmed, the thread is completely invisible on AIOE, and may also be
inaccessible to some other people using conventional newsreaders on
normal USENET servers.

John Savard
http://www.quadibloc.com/index.html

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch

csiph-web