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


Groups > comp.arch > #6267

Re: Hardware for linked lists

From Chris Gray <cg@GraySage.com>
Newsgroups comp.arch
Subject Re: Hardware for linked lists
References <J9R4r.11081$jU1.4604@newsfe08.iad> <jj0o47$e43$1@gosset.csi.cam.ac.uk> <87hay3lxpq.fsf@GraySage.com> <jj1vd6$hbi$1@gosset.csi.cam.ac.uk>
Message-ID <87booalpt3.fsf@GraySage.com> (permalink)
Date 2012-03-05 14:07 -0700

Show all headers | View raw


nmm1@cam.ac.uk writes:

<<trimmed my question>>

> Firstly, the C++ and Boost people believe that a multi-dimensional
> array is the same as a (single-dimensional) array of (s-d) arrays
> of ...  That is a fundamental error, and has been known to be for
> 50 years, because it leads to subsequent mistakes.

This isn't an issue in my Zed - it has proper multi-dimensional arrays.
You can of course have arrays of arrays if you want. I also define the
storage order, but allow a super-optimizing compiler to change it if it
is sure that is safe.

However, I don't see why it is a big issue. In C you can end up with
pointers into the middle of arrays and do really bad things, but that
also allows you to do the slicing thing.

> Secondly, it isn't possible to handle a linear subset (array section)
> as an array in its own right, without taking a copy, as introduced by
> Algol 68.  Despite appearances, Boost views do not cut the mustard,
> because of the first mistake!

Zed does not have this. My friend created (but not implemented) a language
of his own which has "rangers" which allow this. My problem with his
general form of them is that you can end up with a pointer into the middle
of an allocated piece of storage being the only remaining reference to
that storage. In a system that does reference counting or garbage collection,
that adds significantly to the cost, for just that one capability.

I imagine some limited subset of what he does can be done. It is easier
with fixed-size arrays than with dynamically allocated matrices, because
there is no need to decide where the bounds are stored. To allow more
flexible use of some kind of sectioning, an extra chunk of memory is needed,
which can slow down accessing of dynamic matrices.

> Thirdly, the C++ STL is terribly sequential, at a fundamental level,
> and iterators are precisely the wrong concept for such uses.  Most
> array operations are order-independent, which should be reflected
> in the language.

Some of the higher-level languages have things like "map" operators which
operate on entire vectors. These are possible in my language, and could be
defined (by whoever writes them) in such a way as to take advantage of
multiple cores/processors, vector instructions, etc. You don't get the
terse syntax of, say, APL, but that can be a good thing!

--

-Chris Gray

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


Thread

Hardware for linked lists Robert Myers <rbmyersusa@gmail.com> - 2012-03-04 16:29 -0500
  Re: Hardware for linked lists Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-03-04 22:41 +0100
    Re: Hardware for linked lists "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-03-04 20:15 -0800
      Re: Hardware for linked lists "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-03-05 19:53 -0800
        Re: Hardware for linked lists Andrew Reilly <areilly---@bigpond.net.au> - 2012-03-06 11:38 +0000
          Re: Hardware for linked lists nmm1@cam.ac.uk - 2012-03-06 12:16 +0000
        Re: Hardware for linked lists Bakul Shah <usenet@bitblocks.com> - 2012-03-06 23:24 -0800
          Re: Hardware for linked lists Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-03-07 09:08 +0100
    Re: Hardware for linked lists Noob <root@127.0.0.1> - 2012-03-06 13:25 +0100
      Re: Hardware for linked lists Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-03-06 17:11 +0100
  Re: Hardware for linked lists nmm1@cam.ac.uk - 2012-03-04 21:51 +0000
    Re: Hardware for linked lists Robert Myers <rbmyersusa@gmail.com> - 2012-03-04 17:16 -0500
      Re: Hardware for linked lists nmm1@cam.ac.uk - 2012-03-04 23:15 +0000
    Re: Hardware for linked lists Chris Gray <cg@GraySage.com> - 2012-03-04 17:04 -0700
      Re: Hardware for linked lists nmm1@cam.ac.uk - 2012-03-05 09:01 +0000
        Re: Hardware for linked lists Chris Gray <cg@GraySage.com> - 2012-03-05 14:07 -0700
    Re: Hardware for linked lists George Neuner <gneuner2@comcast.net> - 2012-03-05 00:57 -0500
  Re: Hardware for linked lists cjt <cheljuba@prodigy.net> - 2012-03-04 19:09 -0600
  Re: Hardware for linked lists MitchAlsup <MitchAlsup@aol.com> - 2012-03-04 18:24 -0800
    Re: Hardware for linked lists Robert Myers <rbmyersusa@gmail.com> - 2012-03-04 22:26 -0500
  Re: Hardware for linked lists Andrew Reilly <areilly---@bigpond.net.au> - 2012-03-05 03:59 +0000
    Re: Hardware for linked lists Anne & Lynn Wheeler <lynn@garlic.com> - 2012-03-04 23:38 -0500
      Re: Hardware for linked lists Jim Haynes <jhaynes@alumni.uark.edu> - 2012-03-05 11:08 -0600
  Re: Hardware for linked lists jgk@panix.com (Joe keane) - 2012-03-05 22:21 +0000
    Re: Hardware for linked lists Michael S <already5chosen@yahoo.com> - 2012-03-05 15:14 -0800
      Re: Hardware for linked lists John Levine <johnl@iecc.com> - 2012-03-06 01:44 +0000
        Re: Hardware for linked lists Michael S <already5chosen@yahoo.com> - 2012-03-06 00:41 -0800
  Re: Hardware for linked lists torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-03-06 11:19 +0100
    Re: Hardware for linked lists nmm1@cam.ac.uk - 2012-03-06 11:07 +0000

csiph-web