Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

C Programming Language

normalization of pointers...


What is mean by normalization of pointers...Where we use that?

Shraddha wrote:
> What is mean by normalization of pointers...Where we use that?

We don't. There's no such concept in Standard C.

Tell us more about your problem.

--
"A facility for quotation covers the absence of original thought."/Gaudy Night/

Hewlett-Packard Limited                                          registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN          690597 England

On May 30, 6:29 pm, Chris Dollin <chris.dol@hp.com> wrote:

On May 30, 6:29 pm, Chris Dollin <chris.dol@hp.com> wrote:

> Shraddha wrote:
> > What is mean by normalization of pointers...Where we use that?

> We don't. There's no such concept in Standard C.

> Tell us more about your problem.

> --
> "A facility for quotation covers the absence of original thought."/Gaudy Night/

> Hewlett-Packard Limited                                          registered no:
> registered office: Cain Road, Bracknell, Berks RG12 1HN          690597 England

I read about it in the explanation of the far pointers...
there they say that -"The only difference between huge pointers and
far pointers is that...huge pointers are normalized..."

So I am asking what is far pointers?

On May 30, 9:43 am, Shraddha <shraddhajosh@gmail.com> wrote:
[snip]

> So I am asking what is far pointers?

"far" pointers do not exist in C

They exist in some C-like languages (primarily, those designed by
Microsoft) as a way of expressing a pointer on an Intel processor
platform. You probably want to ask your question in either an Intel or
a Microsoft group.

On 5 30 , 9 43 , Shraddha <shraddhajosh@gmail.com> wrote:

The huge pointer and far pointer are old concept which live in 16-bit
DOS time. You can search something about DOS programming for more
detail about them.

Shraddha wrote:
> On May 30, 6:29 pm, Chris Dollin <chris.dol@hp.com> wrote:
>> Shraddha wrote:
>> > What is mean by normalization of pointers...Where we use that?

>> We don't. There's no such concept in Standard C.

>> Tell us more about your problem.

(and remember to snip signatures in the future)

> I read about it in the explanation of the far pointers...
> there they say that -"The only difference between huge pointers and
> far pointers is that...huge pointers are normalized..."

> So I am asking what is far pointers?

They are not a feature of Standard C; they are a non-standard
(and, as I understand it, largely obsolete) feature of certain
implementations.

I'd advise learning C from a source that isn't so implementation-
specific. (My preference is for K&R 2; others differ.)

--
"Who are you? What do you want?"                                    /Babylon 5/

Hewlett-Packard Limited                                          registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN          690597 England

In article <1180532975.780674.67@q69g2000hsb.googlegroups.com>, Lew
Pitcher <lpitc@teksavvy.com> writes

>On May 30, 9:43 am, Shraddha <shraddhajosh@gmail.com> wrote:
>[snip]
>> So I am asking what is far pointers?

>"far" pointers do not exist in C

>They exist in some C-like languages (primarily, those designed by
>Microsoft)

This is not correct. I have lots of compilers, NONE by Microsoft or for
x86 targets that have FAR pointers.

>as a way of expressing a pointer on an Intel processor

Or many others.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <f3k080$td@murdoch.hpl.hp.com>, Chris Dollin
<chris.dol@hp.com> writes

Many compilers have FAR pointers. Not just WinTel stuff. Not just in old
compilers either.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

They are obsolete, used on the obsolete 8086 (not 80x86)
architecture, to provide access to a 1 megabyte address space with
16 bit registers.  Ignore the word 'far'.

--
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
 <http://kadaitcha.cx/vista/dogsbreakfast/index.html>
                        cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Shraddha wrote:

> What is mean by normalization of pointers...Where we use that?

We don't.

--
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
 <http://kadaitcha.cx/vista/dogsbreakfast/index.html>
                        cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Chris Hills wrote:
> In article <f3k080$td@murdoch.hpl.hp.com>, Chris Dollin
> <chris.dol@hp.com> writes
>>Shraddha wrote:
>>> So I am asking what is far pointers?

>>They are not a feature of Standard C; they are a non-standard
>>(and, as I understand it, largely obsolete) feature of certain
>>implementations.

>>I'd advise learning C from a source that isn't so implementation-
>>specific. (My preference is for K&R 2; others differ.)

> Many compilers have FAR pointers.

Perhaps many do. None of those FAR (or `far` or `_far`) pointers
are Standard C, though, which is my main point above.

> Not just WinTel stuff.

I didn't say Windows. Even if I thought it. Did I?

> Not just in old compilers either.

I didn't say "old compilers", either. I understood this /feature/
to be largely /obsolete/; perhaps I'm wrong. Perhaps it depends
on the scope of the "largely".

--
"I'm still here and I'm holding the answers"  - Karnataka, /Love and Affection/

Hewlett-Packard Limited     Cain Road, Bracknell,                registered no:
registered office:          Berks RG12 1HN                       690597 England

On May 30, 10:24 am, Chris Hills <c@phaedsys.org> wrote:

> >> So I am asking what is far pointers?

> >They are not a feature of Standard C; they are a non-standard
> >(and, as I understand it, largely obsolete) feature of certain
> >implementations.

> >I'd advise learning C from a source that isn't so implementation-
> >specific. (My preference is for K&R 2; others differ.)

> Many compilers have FAR pointers. Not just WinTel stuff. Not just in old
> compilers either.

I suppose they target some architectures where the memory model is not
the tiny model. Am I right?
In article <1180542817.992068.15@o5g2000hsb.googlegroups.com>,
Quentin Godfroy <quentin_godf@hotmail.com> writes

Tiny? The first one I just picked up has small, compact and large.  This
depends on if you have external memory or not.  Some versions of the
target hardware, but not all by a long way,  have a physical FAR memory
space hence the pointers. The also have a physical memory that is bit
addressable.

I think that you can actually use the FAR memory with pointers in all
three memory models by  explicit declaration.  I will have to look that
up tomorrow.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Shraddha wrote:

> On May 30, 6:29 pm, Chris Dollin <chris.dol@hp.com> wrote:
> > Shraddha wrote:
> > > What is mean by normalization of pointers...Where we use that?

> > We don't. There's no such concept in Standard C.

> > Tell us more about your problem.

> I read about it in the explanation of the far pointers...
> there they say that -"The only difference between huge pointers and
> far pointers is that...huge pointers are normalized..."

Note that "near", "far", "normalized", and so on are not part of
the C standard.

However, in the context of that original discussion...

Some hardware uses a "segmented" memory architecture.  For example,
the x86 series of processors have a "real mode" mode, in which you
access memory via a pointer consisting of a 16-bit segment and a
16-bit offset, in which the physical address is obtained by taking
(segment*16 + offset).  In such a model, multiple segment/offset
combinations can point to the same physical memory locaation.  For
example F000:FFF0 and FFFF:0000 both point to FFFF0.

In such a model, you can "normalize" the pointer by making sure
that the offset is always less than 0x10.  In other words, if the
physical address ix 0xABCDE, then you normalize it to ABCD:000E.
This guarantees that there is but a single normalized pointer to
any given physical address, and you can compare any normalized
pointers as simple 32-bit values.

> So I am asking what is far pointers?

"Far" pointers consist of both the segment and offset.  A "near"
pointer would consis of just the offset, with the segment value
gotten elsewhere.  (For example, on the x86, it could be either
the DS or SS segment register.)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody        | www.hvcomputer.com | #include              |
| kenbrody/at\spamcop.net | www.fptech.com     |    <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsASpamT@gmail.com>

"Chris Dollin" <chris.dol@hp.com> wrote in message
> I didn't say "old compilers", either. I understood this /feature/
> to be largely /obsolete/; perhaps I'm wrong. Perhaps it depends
> on the scope of the "largely".

Most people program PCs most of the time, and segmented architecture was
dumped years ago. However most chips are not CPUs in computer systems, and a
lot of them come with C compilers, and are fairly low power - you might have
4K of memory of which 256 bytes is RAM, for instance. Obviously you want to
squeeze RAM pointers into 8 bits.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
On Wed, 30 May 2007 21:31:11 +0100, in comp.lang.c , "Malcolm McLean"

<regniz@btinternet.com> wrote:
>"Chris Dollin" <chris.dol@hp.com> wrote in message
>> I didn't say "old compilers", either. I understood this /feature/
>> to be largely /obsolete/; perhaps I'm wrong. Perhaps it depends
>> on the scope of the "largely".

>Most people program PCs most of the time,

I beg to differ. Most people I know programme functionality not
hardware.
And I betcha the number of salaried embedded programmers still
outweighs wintelers.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
 Therefore, if you write the code as cleverly as possible, you are,
 by definition, not smart enough to debug it."
--Brian Kernighan

In article <ff0s53dcohboqf049p7kea8i37rb71h@4ax.com>,
Mark McIntyre  <markmcint@spamcop.net> wrote:

>On Wed, 30 May 2007 21:31:11 +0100, in comp.lang.c , "Malcolm McLean"
><regniz@btinternet.com> wrote:
>>Most people program PCs most of the time,

Datum: I do servers, workstations, appliances, and occasionally my
Palm Pilot[1].  You could make a case for calling the workstation a PC,
but not any of the others, and workstations take up less than half of
my time-spent-programming and, in any given month, probably less than
at least one of the others.  Not exactly "most of the time".

>I beg to differ. Most people I know programme functionality not
>hardware.

The functionality I do is recognizeably, though perhaps not tightly,
bound to the type of hardware (at least at the general-class-of level,
though usually not at the architecture level) it will be running on.

>And I betcha the number of salaried embedded programmers still
>outweighs wintelers.

Datum: At my day job, we ship a system running on Wintel that interfaces
with the outside world as a network-connected appliance (i.e. much the
same way some embedded systems would, and not at all like a PC would),
and everybody involved (including our manager) dreams of eventually moving
it to something that looks and feels more like an embedded system inside
the box as well.  (We'd still need enough memory and CPU cycles that the
*real* embedded programmers would laugh and say "You call that embedded?",
but definitely not something any sensible person would call a PC.)

dave

[1] And I've written some code that could, and probably eventually
    will, run on all of them, with no changes except which compiler I
    feed it to.

--
Dave Vandervies                                   dj3va@csclub.uwaterloo.ca
I presume the difference is that Laurier's off-campus environment includes the
University of Waterloo, whereas the best we can offer by way of off-campus
environment is, well, Laurier. . . .             --Chris Redmond in uw.general

"Mark McIntyre" <markmcint@spamcop.net> wrote in message

news:ff0s53dcohboqf049p7kea8i37rb71hf21@4ax.com...
> On Wed, 30 May 2007 21:31:11 +0100, in comp.lang.c , "Malcolm McLean"
> <regniz@btinternet.com> wrote:

>>"Chris Dollin" <chris.dol@hp.com> wrote in message
>>> I didn't say "old compilers", either. I understood this /feature/
>>> to be largely /obsolete/; perhaps I'm wrong. Perhaps it depends
>>> on the scope of the "largely".

>>Most people program PCs most of the time,

> I beg to differ. Most people I know programme functionality not
> hardware.

In most PC programs most of the time is spent on the user interface. You are
writing to an API, but one very closely tied to the hardware.
That's maybe getting less true than it was. Processors are now fast enough
so you don't need to worry about updating the display efficiently. And there
are more hig-level tools about that arguably make it easier to tack up a UI.

> And I betcha the number of salaried embedded programmers still
> outweighs wintelers.

I don't know. When I did embedded stuff I still spent a great deal of time
writing supporting programs on PCs, though the final product was not a PC
program.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Malcolm McLean wrote:
> "Chris Dollin" <chris.dol@hp.com> wrote in message
>> I didn't say "old compilers", either. I understood this /feature/
>> to be largely /obsolete/; perhaps I'm wrong. Perhaps it depends
>> on the scope of the "largely".

> Most people program PCs most of the time, and segmented architecture was
> dumped years ago. However most chips are not CPUs in computer systems, and a
> lot of them come with C compilers, and are fairly low power - you might have
> 4K of memory of which 256 bytes is RAM, for instance. Obviously you want to
> squeeze RAM pointers into 8 bits.

I am more enlightened than I was; my workstation/PC bias was showing.

--
Yes, Virginia, there is a second Jena user conference:     Palo Alto, Sep 2007.

Hewlett-Packard Limited                                          registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN          690597 England

In article <ff0s53dcohboqf049p7kea8i37rb71h@4ax.com>, Mark McIntyre
<markmcint@spamcop.net> writes

>On Wed, 30 May 2007 21:31:11 +0100, in comp.lang.c , "Malcolm McLean"
><regniz@btinternet.com> wrote:

>>"Chris Dollin" <chris.dol@hp.com> wrote in message
>>> I didn't say "old compilers", either. I understood this /feature/
>>> to be largely /obsolete/; perhaps I'm wrong. Perhaps it depends
>>> on the scope of the "largely".

>>Most people program PCs most of the time,

>I beg to differ. Most people I know programme functionality not
>hardware.
>And I betcha the number of salaried embedded programmers still
>outweighs wintelers.

I would agree.  The thing is most embedded SW people tend to also have a
background in hardware and don't hang around in SW groups because of the
PC bias.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <j-udnQsUUKufQsDbRVny@bt.com>, Malcolm McLean
<regniz@btinternet.com> writes

>"Chris Dollin" <chris.dol@hp.com> wrote in message
>> I didn't say "old compilers", either. I understood this /feature/
>> to be largely /obsolete/; perhaps I'm wrong. Perhaps it depends
>> on the scope of the "largely".

>Most people program PCs most of the time,

That is not correct. However it is a common fallacy put around by those
whose programming stated and ended with PC's

> and segmented architecture was dumped years ago. However most chips
>are not CPUs in computer systems, and a lot of them come with C
>compilers, and are fairly low power -

This is also completely incorrect. Low power as in low power
consumption, yes but I think it is only in the last 2 years that the
average main processor in a PC is more powerful than embedded MCU.
There have been embedded 64 and 128 bit MCU long before the PC started
using 64bit processors.

>you might have 4K of memory

Some 8 bit processors go up to 18Mega. byte

>of which 256 bytes is RAM, for instance. Obviously you want to squeeze
>RAM pointers into 8 bits.

Yes.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

That's simply nonsense.  The modern PC UI API is about as far away form
the hardware as you can get.  Most (with one obvious exception) are
designed to be platform agnostic.

--
Ian Collins.

In article <f3lrul$qm@murdoch.hpl.hp.com>, Chris Dollin
<chris.dol@hp.com> writes

>Malcolm McLean wrote:

>> "Chris Dollin" <chris.dol@hp.com> wrote in message
>>> I didn't say "old compilers", either. I understood this /feature/
>>> to be largely /obsolete/; perhaps I'm wrong. Perhaps it depends
>>> on the scope of the "largely".

>> Most people program PCs most of the time, and segmented architecture was
>> dumped years ago. However most chips are not CPUs in computer systems, and a
>> lot of them come with C compilers, and are fairly low power - you might have
>> 4K of memory of which 256 bytes is RAM, for instance. Obviously you want to
>> squeeze RAM pointers into 8 bits.

>I am more enlightened than I was; my workstation/PC bias was showing.

Just to give you some idea the last survey I saw, it is a paid for trade
one so I cant publish it here,  puts the MCU use in PC's at about 5% of
the total MCU's shipped.

There are something like 100 MCU in the average car these days. Most
PC's have probably a 10 other MCU in them besides the main one.

The most common MCU on the planet  (it think it is 30% by volume) is the
8 bit 8031.

Of course doing it by value changes the numbers quite a bit.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

"Chris Hills" <c@phaedsys.org> wrote in message

news:UQGfIoAfOnXGFAZD@phaedsys.demon.co.uk...
> In article <j-udnQsUUKufQsDbRVny@bt.com>, Malcolm McLean
> <regniz@btinternet.com> writes
>>"Chris Dollin" <chris.dol@hp.com> wrote in message
>>> I didn't say "old compilers", either. I understood this /feature/
>>> to be largely /obsolete/; perhaps I'm wrong. Perhaps it depends
>>> on the scope of the "largely".

>>Most people program PCs most of the time,

> That is not correct. However it is a common fallacy put around by those
> whose programming stated and ended with PC's

Aha. You are not such a limited person. So not subject to the fallacy.

But isn't your pride in that status based on the fact that most people write
programs for PCs?
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc