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


Groups > comp.arch > #25713

Re: Reading the Mill wiki: comments and a concern

From Melzzzzz <mel@zzzzz.com>
Newsgroups comp.arch
Subject Re: Reading the Mill wiki: comments and a concern
Date 2014-12-13 04:36 +0100
Organization albasani.net
Message-ID <20141213043621.6f5313f7@maxa-pc> (permalink)
References <memo.20141212191505.4640d@jgd.cix.co.uk> <m6ffq3$cm$1@dont-email.me> <9ec3af8d-7a34-43a9-861e-3eeaf8a11baf@googlegroups.com> <m6g3nl$9d8$1@dont-email.me>

Show all headers | View raw


On Fri, 12 Dec 2014 17:11:29 -0800
Ivan Godard <ivan@ootbcomp.com> wrote:

> On 12/12/2014 2:54 PM, Quadibloc wrote:
> > On Friday, December 12, 2014 12:31:36 PM UTC-7, Ivan Godard wrote:
> >> Beyond that, we have put a lot of
> >> effort into making the Mill ISA optimization-proof. When code can
> >> be optimized it means that the architecture design was lacking
> >> IMO, YMMV.
> >
> > Now this is an interesting perspective.
> >
> > Generally speaking, the conventional way of thinking of computer
> > architectures is that they present the hardware to the programmer.
> > If it's well designed, the programmer has an opportunity to get
> > lots of performance out of the hardware - but that it's possible to
> > get things wrong, and that there's a right way of using a given
> > computer, is only reasonable.
> >
> > But that is partly thinking from the "old days" - specifically,
> > before the IBM 360 came along, and ended the pattern of having a
> > different ISA for each new machine, specifically designed for that
> > machine's hardware.
> >
> > For a compiler to do things once, rather than chip hardware to do
> > the same things on every loop iteration, seems to make sense. I've
> > recently learned, I think, that why current RISC architectures are
> > the way they are, including some, but not all, features of the
> > original RISC model, is that they are oriented towards removing the
> > need for out-of-order execution.
> >
> > But many RISC chips have OOO implementations now, and that is, I
> > think, not a contradiction of my conclusiion - instead, it's that a
> > RISC design makes it possible to avoid OOO for a given number of
> > pipeline stages; if you have more pipeline stages, then you don't
> > have enough registers to avoid the need for OOO any more.
> >
> > Since the Mill transforms its code once - at load time - to its
> > internal model- dependent code, it avoids that particular bit of
> > wastefulness associated with OOO.
> >
> > John Savard
> >
> 
> Another way to look at my viewpoint is to sat that ISAs should
> directly match what HLLs actually do, before compilation removes all
> the structure that was present in the original program. That is, for
> each construct that is a primitive in the (union of all) HLL, there
> should be one machine operation that does that primitive.
> Optimization is neither necessary nor useful.
> 
> I use our call operation as an example: if the program contains 
> "F(a,b,c)", you get the machine code "call(f,a,b,c)". What else would 
> you want? Why should you deal with things like stack pointers and 
> register saving?

Nice. I cannot imagine doing it without register saving in stack :p

> 
> Yes, HLLs vary in their selection of primitives, and the ISA designer 
> has to make sure that the ISA machine primitives don't leave some HLL
> in the lurch. But at the primitive level HLLs are far more similar
> than different, and the differences tend to be things that have to be
> done by the RTS anyway because they are too complex to move to
> hardware.

Well, there will be ABI? (if not already) and all HLL's honor ABI,
therefore not a problem.
Is there a plan to make something like qemu for Mill so that people
can at least write assembler (and test) for it? 

Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Reading the Mill wiki: comments and a concern jgd@cix.co.uk (John Dallman) - 2014-12-12 19:15 +0000
  Re: Reading the Mill wiki: comments and a concern Ivan Godard <ivan@ootbcomp.com> - 2014-12-12 11:31 -0800
    Re: Reading the Mill wiki: comments and a concern peterfirefly@gmail.com - 2014-12-12 11:46 -0800
      Re: Reading the Mill wiki: comments and a concern Ivan Godard <ivan@ootbcomp.com> - 2014-12-12 12:06 -0800
        Re: Reading the Mill wiki: comments and a concern peterfirefly@gmail.com - 2014-12-12 13:37 -0800
          Re: Reading the Mill wiki: comments and a concern Ivan Godard <ivan@ootbcomp.com> - 2014-12-12 16:50 -0800
    Re: Reading the Mill wiki: comments and a concern jgd@cix.co.uk (John Dallman) - 2014-12-12 20:24 +0000
      Re: Reading the Mill wiki: comments and a concern Ivan Godard <ivan@ootbcomp.com> - 2014-12-12 12:35 -0800
        Re: Reading the Mill wiki: comments and a concern Quadibloc <jsavard@ecn.ab.ca> - 2014-12-12 15:03 -0800
          Re: Reading the Mill wiki: comments and a concern Ivan Godard <ivan@ootbcomp.com> - 2014-12-12 17:01 -0800
    Re: Reading the Mill wiki: comments and a concern Quadibloc <jsavard@ecn.ab.ca> - 2014-12-12 14:54 -0800
      Re: Reading the Mill wiki: comments and a concern Ivan Godard <ivan@ootbcomp.com> - 2014-12-12 17:11 -0800
        Re: Reading the Mill wiki: comments and a concern Melzzzzz <mel@zzzzz.com> - 2014-12-13 04:36 +0100
          Re: Reading the Mill wiki: comments and a concern Ivan Godard <ivan@ootbcomp.com> - 2014-12-12 19:59 -0800

csiph-web