Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #155484 > unrolled thread
| Started by | dfs <nospam@dfs.com> |
|---|---|
| First post | 2020-10-09 20:11 -0400 |
| Last post | 2020-10-10 14:01 -0700 |
| Articles | 20 on this page of 131 — 23 participants |
Back to article view | Back to comp.lang.c
Trick to knowing hex address alignment? dfs <nospam@dfs.com> - 2020-10-09 20:11 -0400
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-09 18:43 -0600
Re: Trick to knowing hex address alignment? dfs <nospam@dfs.com> - 2020-10-09 22:14 -0400
Re: Trick to knowing hex address alignment? Kaz Kylheku <793-849-0957@kylheku.com> - 2020-10-10 01:10 +0000
Re: Trick to knowing hex address alignment? dfs <nospam@dfs.com> - 2020-10-09 22:15 -0400
Re: Trick to knowing hex address alignment? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2020-10-10 01:30 -0400
Re: Trick to knowing hex address alignment? BGB <cr88192@gmail.com> - 2020-10-10 01:30 -0500
Re: Trick to knowing hex address alignment? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2020-10-12 16:58 -0400
Re: Trick to knowing hex address alignment? BGB <cr88192@gmail.com> - 2020-10-14 16:04 -0500
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-10 18:31 +0200
Re: Trick to knowing hex address alignment? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-10-10 09:46 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-10 19:50 +0200
Re: Trick to knowing hex address alignment? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-10-10 18:45 +0000
Re: Trick to knowing hex address alignment? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-10-10 15:05 -0400
Re: Trick to knowing hex address alignment? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-10-10 12:34 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-11 08:10 +0200
Re: Trick to knowing hex address alignment? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-10-11 02:29 -0700
Re: Trick to knowing hex address alignment? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-10-11 12:08 +0100
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-11 13:13 +0200
Re: Trick to knowing hex address alignment? Richard Damon <Richard@Damon-Family.org> - 2020-10-11 15:06 -0400
Re: Trick to knowing hex address alignment? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-10-11 15:27 -0400
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 07:18 +0200
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 08:19 +0200
Re: Trick to knowing hex address alignment? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-10-12 00:43 -0700
Re: Trick to knowing hex address alignment? David Brown <david.brown@hesbynett.no> - 2020-10-12 12:03 +0200
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 13:14 +0200
Re: Trick to knowing hex address alignment? Richard Damon <Richard@Damon-Family.org> - 2020-10-12 08:33 -0400
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 16:21 +0200
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-12 14:07 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 06:58 +0200
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-13 00:10 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 09:53 +0200
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-13 01:25 -0700
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-13 01:31 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 10:34 +0200
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-13 01:47 -0700
Re: Trick to knowing hex address alignment? Kaz Kylheku <793-849-0957@kylheku.com> - 2020-10-13 15:39 +0000
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-13 16:16 -0700
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-12 14:32 +0000
Re: Trick to knowing hex address alignment? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-10-12 07:13 -0700
Re: Trick to knowing hex address alignment? David Brown <david.brown@hesbynett.no> - 2020-10-12 19:16 +0200
Re: Trick to knowing hex address alignment? Vir Campestris <vir.campestris@invalid.invalid> - 2020-10-12 21:26 +0100
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-12 14:08 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 06:50 +0200
Re: Trick to knowing hex address alignment? Vir Campestris <vir.campestris@invalid.invalid> - 2020-10-11 21:16 +0100
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 07:18 +0200
Re: Trick to knowing hex address alignment? arnold@hooterville.invalid (Arnold Ziffel) - 2020-10-13 11:44 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 14:21 +0200
Re: Trick to knowing hex address alignment? arnold@hooterville.invalid (Arnold Ziffel) - 2020-10-13 13:18 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 18:19 +0200
Re: Trick to knowing hex address alignment? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-10-11 14:12 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 07:20 +0200
Re: Trick to knowing hex address alignment? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-10-12 07:09 -0700
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-12 14:35 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 16:37 +0200
Re: Trick to knowing hex address alignment? Bart <bc@freeuk.com> - 2020-10-12 15:51 +0100
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 17:07 +0200
Re: Trick to knowing hex address alignment? Bart <bc@freeuk.com> - 2020-10-12 16:45 +0100
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 17:47 +0200
Re: Trick to knowing hex address alignment? Bart <bc@freeuk.com> - 2020-10-12 17:05 +0100
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 06:46 +0200
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-12 14:19 -0700
Re: Trick to knowing hex address alignment? arnold@hooterville.invalid (Arnold Ziffel) - 2020-10-13 11:48 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 14:22 +0200
Re: Trick to knowing hex address alignment? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-10-13 06:25 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 18:20 +0200
Re: Trick to knowing hex address alignment?, speciall Richard Damon <Richard@Damon-Family.org> - 2020-10-13 12:38 -0400
Re: Trick to knowing hex address alignment?, speciall James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-10-13 12:51 -0400
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-12 11:11 -0600
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-12 18:50 +0000
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-12 13:03 -0600
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-12 19:30 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 06:47 +0200
Re: Trick to knowing hex address alignment? arnold@hooterville.invalid (Arnold Ziffel) - 2020-10-13 11:52 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 14:23 +0200
Re: Trick to knowing hex address alignment? Bart <bc@freeuk.com> - 2020-10-13 14:43 +0100
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-13 08:57 -0600
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 18:21 +0200
Re: Trick to knowing hex address alignment? Bart <bc@freeuk.com> - 2020-10-13 17:38 +0100
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 19:03 +0200
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-13 11:20 -0600
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 19:23 +0200
Re: Trick to knowing hex address alignment? Bart <bc@freeuk.com> - 2020-10-13 18:28 +0100
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 19:30 +0200
Re: Trick to knowing hex address alignment? arnold@hooterville.invalid (Arnold Ziffel) - 2020-10-14 09:24 +0000
Re: Trick to knowing hex address alignment? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-10-14 09:35 -0400
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-15 09:29 +0200
Re: Trick to knowing hex address alignment? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-10-13 10:24 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 19:31 +0200
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-13 14:47 -0700
Re: Trick to knowing hex address alignment? Richard Damon <Richard@Damon-Family.org> - 2020-10-12 21:48 -0400
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 06:49 +0200
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-13 15:24 +0000
Re: Trick to knowing hex address alignment? Richard Damon <Richard@Damon-Family.org> - 2020-10-13 12:32 -0400
Re: Trick to knowing hex address alignment? Vir Campestris <vir.campestris@invalid.invalid> - 2020-10-13 21:55 +0100
Re: Trick to knowing hex address alignment? Vir Campestris <vir.campestris@invalid.invalid> - 2020-10-13 22:00 +0100
Re: Trick to knowing hex address alignment? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-10-13 14:13 -0700
Re: Trick to knowing hex address alignment? David Brown <david.brown@hesbynett.no> - 2020-10-14 13:13 +0200
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-14 15:59 +0000
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-14 11:31 -0600
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-14 19:03 +0000
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-13 09:50 -0600
Re: Trick to knowing hex address alignment? Kaz Kylheku <793-849-0957@kylheku.com> - 2020-10-13 17:41 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 20:07 +0200
Re: Trick to knowing hex address alignment? Kaz Kylheku <793-849-0957@kylheku.com> - 2020-10-15 00:38 +0000
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-14 21:23 -0600
Re: Trick to knowing hex address alignment? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-10-12 11:20 +0100
Re: Trick to knowing hex address alignment? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-10-12 10:19 -0400
Re: Trick to knowing hex address alignment? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-10-10 15:42 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-11 13:14 +0200
Re: Trick to knowing hex address alignment? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-10-11 14:11 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 07:20 +0200
Re: Trick to knowing hex address alignment? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-10-12 00:42 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 13:16 +0200
Re: Trick to knowing hex address alignment? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-10-12 07:22 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 16:23 +0200
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-12 14:35 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 16:40 +0200
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-12 14:09 -0700
Re: Trick to knowing hex address alignment? David Brown <david.brown@hesbynett.no> - 2020-10-12 08:26 +0200
Re: Trick to knowing hex address alignment? Öö Tiib <ootiib@hot.ee> - 2020-10-12 03:19 -0700
Re: Trick to knowing hex address alignment? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-10-12 07:22 -0700
Re: Trick to knowing hex address alignment? arnold@hooterville.invalid (Arnold Ziffel) - 2020-10-13 11:59 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 14:25 +0200
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-13 15:26 +0000
Re: Trick to knowing hex address alignment? DFS <nospam@dfs.com> - 2020-10-13 11:33 -0400
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 18:23 +0200
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-11 09:47 -0600
Re: Trick to knowing hex address alignment? Elias Schwerdtfeger <nachtwaechter@tamagothi.de> - 2020-10-10 18:45 +0200
Re: Trick to knowing hex address alignment? Barry Schwarz <schwarzb@delq.com> - 2020-10-10 10:32 -0700
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-10 14:01 -0700
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2020-10-13 11:20 -0600 |
| Message-ID | <1bd01mf3g1.fsf@pfeifferfamily.net> |
| In reply to | #155635 |
Christian Hanné <the.hanne@gmail.com> writes: >> No, the runtime is exactly the same as well. Since they are >> consecutive instructions in the same program! > > No, the compiler generates different linker meta-information that > instructs the linker to mark the instructions which are to be checked. And how, pray tell, does it accomplish this feat? Does it back-patch the code? Does it mark the memory locations where those instructions will be placed with a "check this" bit? Come on, give it up. There can't possibly be anyone left who thinks you're serious.
[toc] | [prev] | [next] | [standalone]
| From | Christian Hanné <the.hanne@gmail.com> |
|---|---|
| Date | 2020-10-13 19:23 +0200 |
| Message-ID | <rm4nq3$1pta$1@gioia.aioe.org> |
| In reply to | #155636 |
> And how, pray tell, does it accomplish this feat? Does it back-patch > the code? Does it mark the memory locations where those instructions > will be placed with a "check this" bit? The code-pages are marked accordingly and the instructions are looked up in a table.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-10-13 18:28 +0100 |
| Message-ID | <stlhH.45486$VK4.11121@fx44.am4> |
| In reply to | #155635 |
On 13/10/2020 18:03, Christian Hanné wrote: >> No, the runtime is exactly the same as well. Since they are >> consecutive instructions in the same program! > > No, the compiler generates different linker meta-information that > instructs the linker to mark the instructions which are to be checked. Which compilers do that? In the case of gcc it generates .s files first, which contain no such information that distinguishes one pair of instructions in my example from another. But perhaps you might like to post an .s file that shows that meta-information, or post a dump of an object file showing where that information exists. What would the linker do with that info anyway? I also write compilers, including C compilers, and generate no such information. (Actually, they don't use linkers.) Casting a 64-bit pointer value to a 64-bit unsigned integer value is a no-op across all compilers. Try and dispute that... You're talking complete rubbish. But keep it up, this is fun.
[toc] | [prev] | [next] | [standalone]
| From | Christian Hanné <the.hanne@gmail.com> |
|---|---|
| Date | 2020-10-13 19:30 +0200 |
| Message-ID | <rm4o81$t3$1@gioia.aioe.org> |
| In reply to | #155639 |
> Which compilers do that? ... Every conformant compiler.
[toc] | [prev] | [next] | [standalone]
| From | arnold@hooterville.invalid (Arnold Ziffel) |
|---|---|
| Date | 2020-10-14 09:24 +0000 |
| Message-ID | <f079166e-3b98-4742-ad5d-89ddda7afc2a@hooterville.invalid> |
| In reply to | #155640 |
Christian Hanné <the.hanne@gmail.com> wrote: >> Which compilers do that? ... > > Every conformant compiler. Conformant with what? -- Nothing motivates a man more than to see his boss put in an honest day's work.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-10-14 09:35 -0400 |
| Message-ID | <rm6uqg$cpi$1@dont-email.me> |
| In reply to | #155657 |
On 10/14/20 5:24 AM, Arnold Ziffel wrote: > Christian Hanné <the.hanne@gmail.com> wrote: > >>> Which compilers do that? ... >> >> Every conformant compiler. > > Conformant with what? Conformant with Christian Hanné. Doing that would render an implementation non-conformant with the C standard. Conversion of a pointer value to an integer type has an implementation-defined result (6.3.2.5p5). Not undefined behavior, not implementation-defined behavior, but simply an implementation-defined result. That means that the only freedom an implementation has is to define which integer value results from the conversion. An implementation-defined value is an unspecified value (3.19.2), and an unspecified value must be a "valid value of the relevant type", so an implementation doesn't even have the freedom to produce a trap representation from such a conversion. Therefore, if such code was translated in such a way as to cause a privilege check to occur, if that privilege check failed it would render the implementation non-conforming.
[toc] | [prev] | [next] | [standalone]
| From | Christian Hanné <the.hanne@gmail.com> |
|---|---|
| Date | 2020-10-15 09:29 +0200 |
| Message-ID | <rm8tp0$u69$1@gioia.aioe.org> |
| In reply to | #155657 |
>> Every conformant compiler. > Conformant with what? With at least C99 on platforms that have paging.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-10-13 10:24 -0700 |
| Message-ID | <87y2ka3upo.fsf@nosuchdomain.example.com> |
| In reply to | #155633 |
Bart <bc@freeuk.com> writes:
> On 13/10/2020 17:21, Christian Hanné wrote:
>>> Exactly identical code.
>>
>> But the runtime is different.
>
> No, the runtime is exactly the same as well. Since they are
> consecutive instructions in the same program!
>
> Why not admit that either you were mistaken, or that you're just
> having a laugh winding people up?
He won't admit that he's mistaken because he's not merely mistaken.
Nobody could have the specific misconceptions he's pushing by
accident.
He won't admit that he's trolling us because that would spoil his fun.
Every time someone argues with him (or speculates that he's the
same person as some other troll), he has fun. Please stop making
this fun for him.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Christian Hanné <the.hanne@gmail.com> |
|---|---|
| Date | 2020-10-13 19:31 +0200 |
| Message-ID | <rm4oa4$t3$2@gioia.aioe.org> |
| In reply to | #155638 |
> He won't admit that he's mistaken because he's not merely mistaken. > Nobody could have the specific misconceptions he's pushing by > accident. > He won't admit that he's trolling us because that would spoil his fun. > Every time someone argues with him (or speculates that he's the > same person as some other troll), he has fun. Please stop making > this fun for him. Please hold back with your hasty conclusions.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-10-13 14:47 -0700 |
| Message-ID | <rm57a2$k9d$1@gioia.aioe.org> |
| In reply to | #155641 |
On 10/13/2020 10:31 AM, Christian Hanné wrote: >> He won't admit that he's mistaken because he's not merely mistaken. >> Nobody could have the specific misconceptions he's pushing by >> accident. >> He won't admit that he's trolling us because that would spoil his fun. >> Every time someone argues with him (or speculates that he's the >> same person as some other troll), he has fun. Please stop making >> this fun for him. > > Please hold back with your hasty conclusions. LOL!
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-10-12 21:48 -0400 |
| Message-ID | <nH7hH.227195$d95.116820@fx06.iad> |
| In reply to | #155575 |
On 10/12/20 10:37 AM, Christian Hanné wrote: >>> The conversion (uintptr_t)pointer takes hundreds >>> of clock clycles on a CPU today. > >> >> A convertion from (type *) to (uintptr_t) is a no-op on >> x86, x86_64, armv7, armv8 and most other modern CPUs. > > No, it involves a privilege-check on the page referenced. > When you convert the pointer to size_t this doesn't happen. The privilege check will only happen if the pointer is loaded into an 'address' register. A compiler would be very bad to load the pointer into such a register if it isn't being used to access the memory, and especially if arithmatic is going to immediately be done on the value. Such a compiler is almost sure to do the same for a conversion to size_t, so there would be no savings. Perhaps, on a segmented address machine, it would be more efficent to use a special pointer load instruction (if such a thing existed) that loaded both the segment and offset in one step, and that might cause the check, but on such a machine, size_t is probably not sufficient to hold the conversion of the pointer (but maybe enough to just check alignment).
[toc] | [prev] | [next] | [standalone]
| From | Christian Hanné <the.hanne@gmail.com> |
|---|---|
| Date | 2020-10-13 06:49 +0200 |
| Message-ID | <rm3bkg$1ho6$3@gioia.aioe.org> |
| In reply to | #155598 |
> The privilege check will only happen if the pointer is loaded into an > 'address' register. ... As there is no special address-register on x86 this check is always done.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-10-13 15:24 +0000 |
| Message-ID | <5FjhH.127886$MQ.102013@fx14.iad> |
| In reply to | #155598 |
Richard Damon <Richard@Damon-Family.org> writes: >On 10/12/20 10:37 AM, Christian Hanné wrote: >>>> The conversion (uintptr_t)pointer takes hundreds >>>> of clock clycles on a CPU today. >> >>> >>> A convertion from (type *) to (uintptr_t) is a no-op on >>> x86, x86_64, armv7, armv8 and most other modern CPUs. >> >> No, it involves a privilege-check on the page referenced. >> When you convert the pointer to size_t this doesn't happen. > >The privilege check will only happen if the pointer is loaded into an >'address' register. Say what? The privilege check happens when the virtual address is being translated to a physical address by the CPU. Either on behalf of TLB miss for a load or store, or one some architectures certain instructions can do a permissions check (e.g. the ARMv8 "AT" instruction). What's an address register? Every modern architecture has general purpose registers.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-10-13 12:32 -0400 |
| Message-ID | <EEkhH.158197$NB.50157@fx20.iad> |
| In reply to | #155622 |
On 10/13/20 11:24 AM, Scott Lurndal wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> On 10/12/20 10:37 AM, Christian Hanné wrote: >>>>> The conversion (uintptr_t)pointer takes hundreds >>>>> of clock clycles on a CPU today. >>> >>>> >>>> A convertion from (type *) to (uintptr_t) is a no-op on >>>> x86, x86_64, armv7, armv8 and most other modern CPUs. >>> >>> No, it involves a privilege-check on the page referenced. >>> When you convert the pointer to size_t this doesn't happen. >> >> The privilege check will only happen if the pointer is loaded into an >> 'address' register. > > Say what? > > The privilege check happens when the virtual address is > being translated to a physical address by the CPU. Either > on behalf of TLB miss for a load or store, or one some > architectures certain instructions can do a permissions > check (e.g. the ARMv8 "AT" instruction). > > What's an address register? Every modern architecture has > general purpose registers. > > > As Joe mentioned, it could be a segment register, and some processors in the past had distinct 'Data' and 'Address' registers to allow saving a bit in many opcodes/addressing codes for specifying the register (or letting you have twice as many registers as otherwise). Such a machine might pre-validate an address loaded into an address register, but that might not actually delay the main execution (or it wouldn't be worth doing). On such a machine, you wouldn't load the pointer into one of these address register (unless you had a very dumb compiler) as the address registers would support the AND operation. Yes, I don't know of any processor that could be confused as 'modern' (at least for desktop/server level applications, might still be some embedded processors) with such registers, but they did exist, and maybe some of them had protected memory. Maybe the best know would have been the 80X86 with SI, DI, BP, and SP as 'address' registers and AX, BX, CX, DX as data registers. At least on the earlier machines, the opcode definitely favored the data register for arithmetic and the address registers for addressing.
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2020-10-13 21:55 +0100 |
| Message-ID | <rm547v$sdg$1@dont-email.me> |
| In reply to | #155631 |
On 13/10/2020 17:32, Richard Damon wrote: > Yes, I don't know of any processor that could be confused as 'modern' > (at least for desktop/server level applications, might still be some > embedded processors) with such registers, but they did exist, and maybe > some of them had protected memory. The ICL2900 mainframe had a descriptor register for memory addressing. It's a long time ago, but ISTR it had a 32-bit address, a 24 bit bound, and a byte for things like operand size. The accumulator was variable size, 32, 64 or 128 bits. Why can I remember this useless stuff from 40 years ago? I doubt very much there are any running anywhere! Andy
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2020-10-13 22:00 +0100 |
| Message-ID | <rm54i8$ttb$1@dont-email.me> |
| In reply to | #155651 |
On 13/10/2020 21:55, Vir Campestris wrote: > Why can I remember this useless stuff from 40 years ago? I doubt very > much there are any running anywhere! > I'm gobsmacked. They've got one at Bletchley Park, and it's run occasionally! https://www.tnmoc.org/icl-2966 Andy
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-10-13 14:13 -0700 |
| Message-ID | <87r1q14yo0.fsf@nosuchdomain.example.com> |
| In reply to | #155631 |
Richard Damon <Richard@Damon-Family.org> writes:
[...]
> As Joe mentioned, it could be a segment register, and some processors in
> the past had distinct 'Data' and 'Address' registers to allow saving a
> bit in many opcodes/addressing codes for specifying the register (or
> letting you have twice as many registers as otherwise). Such a machine
> might pre-validate an address loaded into an address register, but that
> might not actually delay the main execution (or it wouldn't be worth
> doing). On such a machine, you wouldn't load the pointer into one of
> these address register (unless you had a very dumb compiler) as the
> address registers would support the AND operation.
>
> Yes, I don't know of any processor that could be confused as 'modern'
> (at least for desktop/server level applications, might still be some
> embedded processors) with such registers, but they did exist, and maybe
> some of them had protected memory.
>
> Maybe the best know would have been the 80X86 with SI, DI, BP, and SP as
> 'address' registers and AX, BX, CX, DX as data registers.
>
> At least on the earlier machines, the opcode definitely favored the data
> register for arithmetic and the address registers for addressing.
The 68K series has (had?) distinct address and data registers
(A0..A7, D0..D7). A7 is the stack pointer.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-10-14 13:13 +0200 |
| Message-ID | <rm6mg2$etl$1@dont-email.me> |
| In reply to | #155653 |
On 13/10/2020 23:13, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: > [...] >> As Joe mentioned, it could be a segment register, and some processors in >> the past had distinct 'Data' and 'Address' registers to allow saving a >> bit in many opcodes/addressing codes for specifying the register (or >> letting you have twice as many registers as otherwise). Such a machine >> might pre-validate an address loaded into an address register, but that >> might not actually delay the main execution (or it wouldn't be worth >> doing). On such a machine, you wouldn't load the pointer into one of >> these address register (unless you had a very dumb compiler) as the >> address registers would support the AND operation. >> >> Yes, I don't know of any processor that could be confused as 'modern' >> (at least for desktop/server level applications, might still be some >> embedded processors) with such registers, but they did exist, and maybe >> some of them had protected memory. >> >> Maybe the best know would have been the 80X86 with SI, DI, BP, and SP as >> 'address' registers and AX, BX, CX, DX as data registers. >> >> At least on the earlier machines, the opcode definitely favored the data >> register for arithmetic and the address registers for addressing. > > The 68K series has (had?) distinct address and data registers > (A0..A7, D0..D7). A7 is the stack pointer. > Has. The family still lives, in the guise of ColdFire (and some hobby implementations). But AFAIK there are no new ColdFire devices in the works - Freescale (now part of NXP) have enough with PPC and ARM devices, and are doing little new with their other cores. It's quite possible that loading a value into an A register would trigger a lookup in TLB or other address-related tables. But these would be speculative - it is entirely valid to use the A registers as extra data registers (though fewer instructions can use them directly).
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-10-14 15:59 +0000 |
| Message-ID | <ufFhH.344185$I15.239583@fx36.iad> |
| In reply to | #155653 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >Richard Damon <Richard@Damon-Family.org> writes: >[...] >> As Joe mentioned, it could be a segment register, and some processors in >> the past had distinct 'Data' and 'Address' registers to allow saving a >> bit in many opcodes/addressing codes for specifying the register (or >> letting you have twice as many registers as otherwise). Such a machine >> might pre-validate an address loaded into an address register, but that >> might not actually delay the main execution (or it wouldn't be worth >> doing). On such a machine, you wouldn't load the pointer into one of >> these address register (unless you had a very dumb compiler) as the >> address registers would support the AND operation. >> >> Yes, I don't know of any processor that could be confused as 'modern' >> (at least for desktop/server level applications, might still be some >> embedded processors) with such registers, but they did exist, and maybe >> some of them had protected memory. >> >> Maybe the best know would have been the 80X86 with SI, DI, BP, and SP as >> 'address' registers and AX, BX, CX, DX as data registers. >> >> At least on the earlier machines, the opcode definitely favored the data >> register for arithmetic and the address registers for addressing. > >The 68K series has (had?) distinct address and data registers >(A0..A7, D0..D7). A7 is the stack pointer. Although, loading those registers did not perform any permissions check (which was the genesis of this thread by bonnie's sockpuppet). Many older architectures had only one register, if they had registers at all. e.g. Burroughs B5500 and HP-3000 (stack based) or the various memory-to-memory architectures (Burroughs B3500, IBM 1401, IBM 1620) are examples. Several had reserved locations in memory that could be used as 'index' registers. In the Burroughs cases, permission checking happened when memory was accessed.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2020-10-14 11:31 -0600 |
| Message-ID | <1b8sc8g1e8.fsf@pfeifferfamily.net> |
| In reply to | #155661 |
scott@slp53.sl.home (Scott Lurndal) writes: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>The 68K series has (had?) distinct address and data registers >>(A0..A7, D0..D7). A7 is the stack pointer. > > Although, loading those registers did not perform any permissions check (which > was the genesis of this thread by bonnie's sockpuppet). > > Many older architectures had only one register, if they had registers at > all. e.g. Burroughs B5500 and HP-3000 (stack based) or the various > memory-to-memory architectures (Burroughs B3500, IBM 1401, IBM 1620) > are examples. Several had reserved locations in memory that could be > used as 'index' registers. > > In the Burroughs cases, permission checking happened when memory > was accessed. The only exception I know of to that rule (you check memory protections when you access memory) was the 286 checking when you loaded a segment register. In that case, no one in their right mind would ever load a segment register unless they were planning to access that memory segment, so it made sense. I wouldn't be at all surprised to learn of other segmented architectures that behaved the same way, but I don't know of them.
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web