«

On Sunday, September 2, 2012 11:47:23 AM UTC+8, Richard Damon wrote:
> On 8/30/12 7:47 AM, Malcolm McLean wrote:
>
> > בתאריך יום חמישי, 30 באוגוסט 2012 02:09:02 UTC+1, מאת Les Cargill:
>
> >> Keith Thompson wrote:
>
> >>
>
> >> The C89 flavors of MSC supported both "void*" and "near"/"far". TINY
>
> >> MODEL FTW!
>
> >>
>
> > The idea of the "models" was that you could write program without the
>
> > near/far non-standard extensions. Under "huge", if I remember rightly,
>
> > all pointers were 32 bit and it did some inefficient magic to hide the
>
> > segments and give you what looked like flat memory. Under "large",
>
> > pointers were 32 bits but you couldn't allocate a block of more than
>
> > 64 K.
>
> > Under "tiny" all code and data had to fit within the same 64K segment,
>
> > which led to the most efficient machine code. But you could use far
>
> > pointers to allocate data in other segments. So you ended up rewriting
>
> > fucntions like "farmemcpy", because the standard library only worked
>
> > with the standard pointers.
>
> >
>
> >
>
> >
>
> >
>
>
>
> The models came about due to the memory structure of the 16 bit x86
>
> architecture. Addresses were in general greater than 16 bits in length,
>
> while address registers were only 16 bits long, and were combined with a
>
> "segment register" to convert the value to a full address. (depending on
>
> what mode the processor was in would change how the conversion was done).
>
>
>
> Near pointers only stored the value of the address register, and the
>
> segment register was assumed by the type of pointer (the Data Segment
>
> Register for "data" pointers, and the Program Segment Register for
>
> function pointers). In addition, data pointers had a huge type, which
>
> was like a far pointer, but could point to an object that might be
>
> bigger than a single segment, and the compiler would need to do
>
> additional work on address arithmetic to handle this. It mostly was used
>
> in "Real" mode, where the Segment register was just added to the address
>
> register after shifting up the Segment register 4 bits (giving a 20 bit
>
> final memory address).
>
>
>
> The program model determined what were the default sizes for each type
>
> of pointer.
>
>
>
> Model Data Code
>
> Tiny near near
>
> Small near near
>
> Medium near far
>
> Compact far near
>
> Large far far
>
> Huge huge far
>
>
>
> The difference between Tiny and Small was that in Tiny, the code and
>
> data were in the same segment, while in Small they were in distinct
>
> segments.
>
>
>
> It was by far more common to have near/far pointers in code that had a
>
> default near size of pointers, to handle a limited number of
>
> objects/functions that would be placed outside the default near block to
>
> make room for them, sometimes to access things outside the current program.
>
>
>
> Note also that the 32 bit x86 family of processors still have these
>
> memory models (and 48 bit "far" pointers), they are just mostly ignored
>
> and most programs are just done in the Tiny or Small model, after all
>
> who should need more than 4GB of address space The resurgence of
>
> memory models for programs was headed off (for now at least) with the
>
> introduction of 64 bit processors.

These are old tricks. Now there are 4 to 8 core cpus in the tablet computers,
or note book computers running Androids( LINUX+JAVA by a new name for marketing).

How to support the multi-core part in C is still not addressed very well?

On 9/2/12 7:43 AM, 88888 Dihedral wrote:
>
> How to support the multi-core part in C is still not addressed very well?
>
>
>

Until the latest standard came out, "ISO Standard C" had no concept of
"threads", and without threads, the issues of a multi-core CPU are
irreverent. Any program that wanted to use threads had to rely on some
other standard of some sort to implement the threads and that standard
needed to define how to handle the various issues with multiple cores.

There is no inherent problem with this, most real programs actually are
going to depend on some standard beyond "ISO Standard C", if only the
documentation of the compiler, many times on something like POSIX or the
like.

With the new standardization of some basic thread supporting primitives
in ISO C, the capability to write more stuff in strictly conforming ISO
Standard C is available (once support becomes common), so perhaps some
programs that used to have a requirement on say POSIX, can now just
require C11 compliance, but most are still going to be dependent on
things beyond the ISO C standard.

I would suspect that in reality, most code for a program should be
fairly agnostic to the multi-core nature of the machine, as it should be
dealing with data that it currently "owns" and the interfaces that pass
data from one thread to another should deal with all the needed memory
barriers to make sure this "just works". It is only the sections that
need to deal with actually sending information between threads that
needs to worry about these aspects, and in most cases the threading
library will provide a "good enough" interface (if a bit heavy). It is
only the case where trying to improve efficiency that the applications
programmer is going to need to deal with these details, and in most
cases when dealing with improving efficiency, there is a tendency to
move into implementation defined/specific characteristics anyway (how
expensive things are tends to be a function of the implementation).

Keith Thompson <kst-> writes:

> Barry Schwarz <> writes:
>> On Mon, 27 Aug 2012 13:35:35 -0700 (PDT), wrote:
> [snip]
>
>>>The i term added to a is being added to the base address of the array
>>>and itself, i, representing the size of a row. j then adds to that
>>>address giving the column position.
>>
>> When a pointer and an integer are added, the value of the integer is
>> scaled by the size of the object pointed to, or if you prefer, the
>> size of the object type pointed to.
>
> Another way to look at it is that the value is *not* "scaled" by the
> size of the object pointed to; rather, the addition yields a pointer
> that points N *objects* past the object that the original pointer
> points to. (There has to be an array for this to make sense, possibly
> the 1-element array that's equivalent to a single object.)
>
> The standard's description doesn't talk about scaling (N1570 6.5.6p:
> [snip quoted paragraph]

But, talking about the [] array indexing operator, the Standard
does say in a footnote

Then i is adjusted according to the type of x, which
conceptually entails multiplying i by the size of the
object to which the pointer points

I'm not arguing for or against either explanation; I think both
have some support (as an explanation) in the Standard.