Re: New assembly language instructions to support OO languages?

Morten Reistad <first@last.name>
Fri, 12 Dec 2008 01:09:14 +0100

          From comp.compilers

Related articles
[29 earlier articles]
Re: New assembly language instructions to support OO languages? gneuner2@comcast.net (George Neuner) (2008-12-09)
Re: New assembly language instructions to support OO languages? jasen@xnet.co.nz (Jasen Betts) (2008-12-09)
Re: New assembly language instructions to support OO languages? efeustel@hughes.net (Edward Feustel) (2008-12-09)
Re: New assembly language instructions to support OO languages? gah@ugcs.caltech.edu (Glen Herrmannsfeldt) (2008-12-09)
Re: New assembly language instructions to support OO languages? kamalpr@hp.com (kamal) (2008-12-10)
Re: New assembly language instructions to support OO languages? jasen@xnet.co.nz (Jasen Betts) (2008-12-11)
Re: New assembly language instructions to support OO languages? first@last.name (Morten Reistad) (2008-12-12)
Re: New assembly language instructions to support OO languages? torbenm@pc-003.diku.dk (2008-12-12)
Re: New assembly language instructions to support OO languages? johnzabroski@gmail.com (John \Z-Bo\Zabroski) (2008-12-13)
Re: New assembly language instructions to support OO languages? bear@sonic.net (Ray Dillinger) (2008-12-13)
Re: New assembly language instructions to support OO languages? jasen@xnet.co.nz (Jasen Betts) (2008-12-14)
Re: New assembly language instructions to support OO languages? gavin@allegro.com (2008-12-16)
| List of all articles for this month |

From: Morten Reistad <first@last.name>
Newsgroups: comp.compilers,comp.arch
Date: Fri, 12 Dec 2008 01:09:14 +0100
Organization: Forte Inc. http://www.forteinc.com/apn/
References: 08-12-025 08-12-039
Keywords: OOP, architecture
Posted-Date: 12 Dec 2008 10:31:11 EST

  <jgd@cix.compulink.co.uk> wrote:
>tony@my.net (Tony) wrote:
>
>> I looked into this 10 years ago and convinced myself that the
>> segmented architecture is still there but that the segments are
>> just now very large (move from 16 to 32 bit?). (Is that the case?).
>
>Yes. As the moderator of comp.compilers pointed out, every x86
>processor, including the 64-bit ones, has a segmentation system that
>nobody uses, except for operating system writers. Segments are 32-bit
>sized in 32-bit mode, and 64-bit sized, really huge, in 64-bit mode.
>
>I've done programming with segments on 16-bit systems, and found it very
>painful, even if one wasn't hitting segment size limits. I've also
>programmed bank-switched memory systems, which have a certain amount in
>common with segmentation, and they're horrible too.
>
>It is easy to construct scenarios where segmentation is advantageous,
>but proponents of the idea tend to neglect the cases where it is no use,
>and the ones where it's a complete pain.
>
>Segmentation is fine as a means for isolating processes from each other,
>and that's how it gets used. If a means could be created for it to
>enforce memory protection of objects from bad pointers, without
>requiring large hardware or performance overheads, that would be
>interesting. But it's going to take more cleverness than is so far
>visible to make that work.


You are 7 years late to this boat. It has been done; for x86 mostly in
the 2001-2004 timeline, and is mainstream now.


Done in OpenBSD from 3.4 onwards, where code, stack, text, linkage and
data are in distinct segments with hardware protection. This is to
avoid stack-smashing attacks and reinforce isolation between
modules. See Theo de Raadt's papers on the issue, or for a quick
intro:


http://en.wikipedia.org/wiki/OpenBSD_security_features (see W^X )
http://en.wikipedia.org/wiki/W%5EX ,
http://www.cis.upenn.edu/~cis551/2005/lectures/cis551-12.pdf


Migrated to Linux as the "Exec Shield" patches, early adopted
(an developed) in Redhat versions, but is mainstream now.


  http://en.wikipedia.org/wiki/Exec_Shield ,


>Bringing back segmentation for everyday programming because the idea
>appeals ... it's like claiming that airliners should have piston engines
>again because they make a cool noise. The idea only makes any sense if
>you don't understand the issues.


Linux and BSDs have always had a segmented view onto memory; it has just
been mapped into one, huge, memory space for the user programs.


The implementation differs. Linux has one segment set per proces, and
lets the dynamic linkage adapt to that; whereas the BSDs have lots of
small segements mapped to the various dynamic objects.


-- mrr


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.