Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #14234
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Newsgroups | comp.lang.c, comp.lang.c++ |
| Subject | Re: malloc |
| Date | 2012-02-18 15:30 +0000 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <jhog6s$331$1@speranza.aioe.org> (permalink) |
| References | (2 earlier) <jhk2rh$19o$1@news.albasani.net> <Xns9FFCE79A6CA00myfirstnameosapriee@216.196.109.131> <01725059-5441-4441-804e-a201c15eeea1@m3g2000pbi.googlegroups.com> <jhn46t$dlp$1@news.albasani.net> <Xns9FFD68EF620ADmyfirstnameosapriee@216.196.109.131> |
Cross-posted to 2 groups.
In comp.lang.c++ Paavo Helde <myfirstname@osa.pri.ee> wrote: (snip) >> the CPU to really make something like this all that workable, even >> then it would still likely be page-fault driven slowness). > This has been done in hardware as well. > http://en.wikipedia.org/wiki/Bounds_checking mentions VAX, B6500 and > Burroughs. By some reason this approach has not really catched on. As I remember VAX allows pages to be marked read-only. I remember Fortran compilers that would put constants in read-only pages, such that they couldn't accidentally be modified. With call-by-reference, modification of constants has a long history in Fortran. >> one option that could sort of work for larger arrays would be >> to put unused pages between memory objects, such that going >> out of bounds is more likely to trigger a page fault. > This is exactly what Electric Fence does. It is also slow as hell, > I guess the most slowdown comes from where the array ends in > a middle of a virtual memory page and efence (snip) In the 16 bit OS/2 days, when most people were still using 16-bit DOS, I would allocate arrays by directly calling the OS/2 segment allocation routine, for a segment exactly the size required. That length then goes into the hardware segment descriptor register, such that hardware tests the bounds, even on fetch. That was before paging, though. (Eventually you run into the 8K segment descriptor per process limit, but usually it works pretty well.) If Intel had added a segment descriptor cache to any of the processors, it would have greatly speeded up some of the things that were done in the 16 bit, and early 32 bit, OS/2 days. If done right, it would have delayed the need for 64 bit processors by some years. -- glen
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
malloc jgk@panix.com (Joe keane) - 2012-02-16 21:04 +0000
Re: malloc Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-16 13:21 -0800
Re: malloc BGB <cr88192@hotmail.com> - 2012-02-16 16:16 -0700
Re: malloc Paavo Helde <myfirstname@osa.pri.ee> - 2012-02-17 14:46 -0600
Re: malloc Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-17 14:51 -0800
Re: malloc BGB <cr88192@hotmail.com> - 2012-02-17 19:58 -0700
Re: malloc Paavo Helde <myfirstname@osa.pri.ee> - 2012-02-18 02:18 -0600
Re: malloc BGB <cr88192@hotmail.com> - 2012-02-18 01:58 -0700
Re: malloc glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-02-18 15:30 +0000
Re: malloc Kaz Kylheku <kaz@kylheku.com> - 2012-02-18 10:36 +0000
Re: malloc William Ahern <william@wilbur.25thandClement.com> - 2012-02-18 16:43 -0800
Re: malloc BGB <cr88192@hotmail.com> - 2012-02-18 20:03 -0700
Re: malloc Miles Bader <miles@gnu.org> - 2012-02-19 12:49 +0900
Re: malloc William Ahern <william@wilbur.25thandClement.com> - 2012-02-18 21:08 -0800
Re: malloc "io_x" <a@b.c.invalid> - 2012-02-19 18:23 +0100
Re: malloc William Ahern <william@wilbur.25thandClement.com> - 2012-02-18 21:06 -0800
Re: malloc BGB <cr88192@hotmail.com> - 2012-02-18 23:06 -0700
Re: malloc "Asger Joergensen" <Junk@Asger-P.dk> - 2012-02-19 15:54 +0000
Re: malloc BGB <cr88192@hotmail.com> - 2012-02-19 09:37 -0700
Re: malloc Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-16 20:27 -0500
Re: malloc Goran <goran.pusic@gmail.com> - 2012-02-16 23:40 -0800
Re: malloc Keith Thompson <kst-u@mib.org> - 2012-02-17 02:26 -0800
Re: malloc Goran <goran.pusic@gmail.com> - 2012-02-17 04:01 -0800
Re: malloc Keith Thompson <kst-u@mib.org> - 2012-02-17 09:25 -0800
Re: malloc 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-17 09:37 -0800
Re: malloc Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-17 14:49 -0800
Re: malloc glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-02-18 01:43 +0000
Re: malloc Kaz Kylheku <kaz@kylheku.com> - 2012-02-18 02:04 +0000
Re: malloc scott@slp53.sl.home (Scott Lurndal) - 2012-02-18 03:04 +0000
Re: malloc Robert Wessel <robertwessel2@yahoo.com> - 2012-02-17 22:15 -0600
Re: malloc Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-17 23:48 -0800
Re: malloc Kaz Kylheku <kaz@kylheku.com> - 2012-02-17 23:29 +0000
Re: malloc Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-17 08:06 -0500
Re: malloc Goran <goran.pusic@gmail.com> - 2012-02-18 07:57 -0800
Re: malloc Keith Thompson <kst-u@mib.org> - 2012-02-18 10:57 -0800
Re: malloc Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-19 08:51 -0500
Re: malloc scott@slp53.sl.home (Scott Lurndal) - 2012-02-17 20:31 +0000
Re: malloc Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-18 00:01 -0800
Re: malloc scott@slp53.sl.home (Scott Lurndal) - 2012-02-18 17:07 +0000
Re: malloc Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-18 18:14 -0800
Re: malloc scott@slp53.sl.home (Scott Lurndal) - 2012-02-19 17:14 +0000
Re: malloc Goran <goran.pusic@gmail.com> - 2012-02-16 23:43 -0800
Re: malloc "io_x" <a@b.c.invalid> - 2012-02-19 16:44 +0100
csiph-web