Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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