Unix Programming - equivalent to far in linux/unix

Author

equivalent to far in linux/unix

Andrew Falanga

2004-08-28, 7:48 am

Hello,

Don't know if the subject line makes sense but here'goes anyway. I
asked in comp.os.msdos.programmer what on earth far is. Actually, found
out that one can be near, far and huge; all depends on where one wants
to put their data.

It sounds as though far is typedef'd as some sort of 32 bit int.
Perhaps, I could be totally wrong too. Except for two very simple dos
prompt programs, I've never programmed for M$. (I'd actually like to
keep it that way.)

In any event, I was wondering if anyone here could tell me what the far
type would translate too in linux? For example, how would I read a line
like this?:

void far *LinkAddress;

What the heck is going on there? I thought void was a type. How can
you have two types for the same variable? Would that simply be
something like?:

int *LinkAddress;

Thanks in advance.

---------------------------------------------
Andrew R. Falanga (a non-HP employee)
Hewlett-Packard Company
11311 Chinden Blvd.
Boise, Idaho
---------------------------------------------
Please note: The e-mail address is purposely
mangled. I do not wish my account at HP to
become a spam haven.

Jens.Toerring@physik.fu-berlin.de

2004-08-28, 7:48 am

Andrew Falanga <falandr@hp.com> wrote:
> Don't know if the subject line makes sense but here'goes anyway. I
> asked in comp.os.msdos.programmer what on earth far is. Actually, found
> out that one can be near, far and huge; all depends on where one wants
> to put their data.

> It sounds as though far is typedef'd as some sort of 32 bit int.
> Perhaps, I could be totally wrong too. Except for two very simple dos
> prompt programs, I've never programmed for M$. (I'd actually like to
> keep it that way.)

Me too;-)

> In any event, I was wondering if anyone here could tell me what the far
> type would translate too in linux?

To nothing. To Linux all memory was created equal, so there's nothing
like near, far or huge (and what you use are virtual addresses anyway,
not physical addresses like under DOS, so where a variable is going to
end up in physical memory is completely unspecified during compilation
and may even still change while the program is running). If you have a
program using them that you want to port to Linux just delete them or
define them to do nothing, e.g.

#define far

> For example, how would I read a line
> like this?:

> void far *LinkAddress;

> What the heck is going on there? I thought void was a type. How can
> you have two types for the same variable?

That's not another type but a (non-standard) additional qualifier.
It's not that uncommon, you can have other, standard qualifiers like

void const *Fixed_Port_Address = 0x378;

or

const void *Read_Only_Address;

etc. That doesn't make 'const' an additional type but qualifies the
type, i.e. that the pointer is to be taken to be unmutable or what
it points to.
Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
\__________________________ http://www.toerring.de

Martin Blume

2004-08-28, 7:48 am

"Andrew Falanga" schrieb
>
> I asked in comp.os.msdos.programmer what on earth far is.
> Actually, found out that one can be near, far and huge; all
> depends on where one wants to put their data.
>

I have to grab this out from the crusted depths of my memory,
so what I say may not be entirely accurate.

NEAR, FAR and HUGE have to do with the memory model of DOS
(remember, this was when somebody said "640 kB will be enough
for anybody"). AFAIK DOS programs could address only 64 kB
chunks, because
- the processor used two registers for addressing data
(and code ?); addresses were specified as segment:offset
(and offset could only specify 64 kB)
- the compiler always kept the same value for the segment if
not told otherwise by the NEAR, FAR and HUGE modifiers.

These modifiers then told the compiler "the address is stored
in two registers, you'll have to load both before you can
access this memory location".

My Microsoft C Reference from 1990 (blurb on the back page:
"making it all make sense"), tells me the following about
memory models:
- tiny: code and data limited to 64 kB total
- small: code and data limired to 64 kB each
- medium: data limited to 64 kB
- compact: code limited to 64 kB
- large: no limits on code or data
- huge: same as large, individual arrays can exceed 64 kB (*)

(*) IIRC, a structure could not straddle two 64 kB chunks,
you'd have to take care it was in one OR the other.

When porting these old programs, I think you can just #define
NEAR, FAR and HUGE away, because modern operating systems
(Linux from the beginning?, Windows from W95 on?) don't have
this memory model, they just operate on a gigantic flat array
of memory. (Might have something to do with the MMU being
built in right into the processor, AFAIK the 8086 didn't have
this).

That's what I remember from these old times. But my memories
may be wrong.

HTH. YMMV.
Martin

Andre Majorel

2004-08-28, 3:18 pm

On 2004-08-27, Andrew Falanga <falandr@hp.com> wrote:

> In any event, I was wondering if anyone here could tell me what the far
> type would translate too in linux? For example, how would I read a line
> like this?:
>
> void far *LinkAddress;
>
> What the heck is going on there? I thought void was a type. How can
> you have two types for the same variable? Would that simply be
> something like?:
>
> int *LinkAddress;

Yes. To port DOS C code to a flat memory model environment such
as i386 Linux, you can just remove the "far" and "huge"
qualifiers, and use malloc() instead of farmalloc() and halloc()
and free() instead of farfree() and hfree().

#define far
#define farmalloc malloc
#define farfree free
#define huge
#define halloc malloc
#define hfree free

The "far" and "huge" qualifiers are an artefact of the segmented
architecture of the 8086. On the 8086, pointers can be 16-bit
long or 32-bit long. A "far" or "huge" qualifier states that
this is a 32-bit pointer. This is necessary when you have more
the 64 kB of code or data.

Conversely, "near" states that this is a 16-bit pointer.

In the absence of a qualifier, pointers use the default model,
which can be near, far or huge, as specified by the relevant
compiler flags.

> It sounds as though far is typedef'd as some sort of 32 bit int.
> Perhaps, I could be totally wrong too.

"far" means that the pointer is made of a 16-bit segment number
plus a 16-bit offset. The total size is indeed 32-bit although
the addressable space is only 20-bit because the 8086 calculates
the effective address like this : segment << 4 + offset.

A "near" pointer is just a 16-bit offset. The segment number is
implied and comes from the relevant segment register (CS for
code, DS for data, etc.) The advantage of near pointers is that
they're small and fast. The drawback is that you're limited to
64 kB of code and 64 kB of data.

"huge" is the same thing as "far" except that the object can be
larger than 64 kB.

--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
"See daddy ? All the keys are in alphabetical order now."

Jem Berkes

2004-08-28, 3:18 pm

> In any event, I was wondering if anyone here could tell me what the far
> type would translate too in linux? For example, how would I read a line
> like this?:

Takes me back to my DOS assembler days

tiny, compact, small, etc. were
memory models. They just helped a compiler organize where in memory they
would place chunks of code, and chunks of data.

With modern OS's where you have virtual memory, you just see a flat 32-bit
address space. The OS takes care of shuffling where it wants to put your
pages of memory in physical RAM or disk, and you don't worry about it.

In pure DOS, memory was available as segment:offset where both were 16-bit
values. Because instructions normally execute within one offset at a time,
you were pretty much limited to 16 bits = 64 KBytes of memory. So the
question became, where are you going to put your code, data, and stack.
With the tiny model you would shove them all within one segment for
instance. With the larger models the compiler did strange tricks to make
use of multiple segments, escaping from the 64 KB limit.

--
Jem Berkes
http://www.sysdesign.ca/

Mike McGinn

2004-08-28, 3:18 pm

Jem Berkes wrote:

>
> Takes me back to my DOS assembler days

tiny, compact, small, etc. were
> memory models. They just helped a compiler organize where in memory they
> would place chunks of code, and chunks of data.
>
> With modern OS's where you have virtual memory, you just see a flat 32-bit
> address space. The OS takes care of shuffling where it wants to put your
> pages of memory in physical RAM or disk, and you don't worry about it.
>
> In pure DOS, memory was available as segment:offset where both were 16-bit
> values. Because instructions normally execute within one offset at a time,
> you were pretty much limited to 16 bits = 64 KBytes of memory. So the
> question became, where are you going to put your code, data, and stack.
> With the tiny model you would shove them all within one segment for
> instance. With the larger models the compiler did strange tricks to make
> use of multiple segments, escaping from the 64 KB limit.
>
I remember using DOS to write test software for modules where we had to test
and keep track of 96 channels of data. You had to be very careful even with
lage model to keep from running agains the segment limit, this was a
problem with MSC ver 4 though 6, despite what the documentation implied. I
generally used float instead of double for data types, and did not keep as
much data around as I wanted to.

--
Mike McGinn

Andrew Falanga

2004-09-02, 6:50 pm

Thank you all for your responses. Sounds like this won't be as much a
deal as I thought. Whoever, or whomever, thought up virtual memory ...
thank you. This other models sounds rather like a pain to work with.

Thanks again everyone.

---------------------------------------------
Andrew R. Falanga (a non-HP employee)
Hewlett-Packard Company
11311 Chinden Blvd.
Boise, Idaho
---------------------------------------------
Please note: The e-mail address is purposely
mangled. I do not wish my account at HP to
become a spam haven.

Rich Teer

2004-09-02, 6:50 pm

On Mon, 30 Aug 2004, Andrew Falanga wrote:

> Thank you all for your responses. Sounds like this won't be as much a
> deal as I thought. Whoever, or whomever, thought up virtual memory ...
> thank you. This other models sounds rather like a pain to work with.

Virtual memory has only been around, oh, about 10 years BEFORE the first
version of DOS shipped. That such hacks such as "near" and "far" show
how brain damaged the design of the original x86 was* and how brain damaged
DOS was, even in the era of 386 and newer x86 CPUs.

* The equivelent motorola chip, the 68000 did not make such a mistake.
What a shame the designers of the original IBM PC didn't chose this
much better CPU for their creation...

--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming",
published in August 2004.

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

Jem Berkes

2004-09-02, 6:50 pm

> Virtual memory has only been around, oh, about 10 years BEFORE the
> first version of DOS shipped. That such hacks such as "near" and
> "far" show how brain damaged the design of the original x86 was* and
> how brain damaged DOS was, even in the era of 386 and newer x86 CPUs.

Well the x86 wasn't that bad for its day, but what is unfortunate is how
long it took mainstream operating PC operating systems (really, DOS/win) to
catch up to the capabilities of the 80386.

--
Jem Berkes
http://www.sysdesign.ca/

Rich Teer

2004-09-02, 6:50 pm

On Mon, 30 Aug 2004, Jem Berkes wrote:

> Well the x86 wasn't that bad for its day, but what is unfortunate is how

Yes it was--the 68000 is proof of that!

> long it took mainstream operating PC operating systems (really, DOS/win) to
> catch up to the capabilities of the 80386.

Agreed. That's what happens when you have a monopoly that isn't
interested in innovation.

--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming",
published in August 2004.

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

Andre Majorel

2004-09-02, 6:50 pm

On 2004-08-30, Andrew Falanga <falandr@hp.com> wrote:

> Thank you all for your responses. Sounds like this won't be as much a
> deal as I thought. Whoever, or whomever, thought up virtual memory ...
> thank you.

A segmented memory model and support for virtual memory are
largely orthogonal issues. The 8086 has the first but not the
second. The 68030 has the second but not the first. The 80286
has both. The 68000 has neither.

--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
Conscience is what hurts when everything else feels so good.

Andre Majorel

2004-09-02, 6:50 pm

On 2004-08-30, Rich Teer <rich.teer@rite-group.com> wrote:
> On Mon, 30 Aug 2004, Andrew Falanga wrote:
>
>
> Virtual memory has only been around, oh, about 10 years BEFORE the
> first version of DOS shipped. That such hacks such as "near" and
> "far" show how brain damaged the design of the original x86 was* and
> how brain damaged DOS was, even in the era of 386 and newer x86 CPUs.
>
> * The equivelent motorola chip, the 68000 did not make such a mistake.
> What a shame the designers of the original IBM PC didn't chose this
> much better CPU for their creation...

Agreed, but... I read somewhere that designing the PC around the
68000 would have increased its price by 20% or 30%. I haven't
found a detailed discussion of how they arrived at that figure,
but I imagine that one of the factors is that 68000 code is not
as compact since all addresses are 32-bit.

Pity, really, considering the repulsive mess that is the 8086
instruction set.

--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
Conscience is what hurts when everything else feels so good.

Dan Mercer

2004-09-02, 6:51 pm

"Andre Majorel" <amajorel@teezer.fr> wrote in message news:slrncj7k49.2pt.amajorel@atc5.vermine.org...
: On 2004-08-30, Rich Teer <rich.teer@rite-group.com> wrote:
: > On Mon, 30 Aug 2004, Andrew Falanga wrote:
: >
: >> Thank you all for your responses. Sounds like this won't be as much a
: >> deal as I thought. Whoever, or whomever, thought up virtual memory ...
: >> thank you. This other models sounds rather like a pain to work with.
: >
: > Virtual memory has only been around, oh, about 10 years BEFORE the
: > first version of DOS shipped. That such hacks such as "near" and
: > "far" show how brain damaged the design of the original x86 was* and
: > how brain damaged DOS was, even in the era of 386 and newer x86 CPUs.
: >
: > * The equivelent motorola chip, the 68000 did not make such a mistake.
: > What a shame the designers of the original IBM PC didn't chose this
: > much better CPU for their creation...
:
: Agreed, but... I read somewhere that designing the PC around the
: 68000 would have increased its price by 20% or 30%. I haven't
: found a detailed discussion of how they arrived at that figure,
: but I imagine that one of the factors is that 68000 code is not
: as compact since all addresses are 32-bit.

I am willing to bet the abusive corporate "personality" at motorola probably
had something to do with it. If they had manufactired 68000 chips
in the numbers required they could have easily cut the per chip price and
still made tons of profit. That just wasn't their style.

They liked to sucker in vendors, dangle huge contracts in front of them,
all on spec, and get free services, often for years. When I worked
for Comten they did that to us after previously doing it to the company
we replaced. Comten showed them - they went out of business.

I personally observed two managers in a data center stand toe to toe
screaming at each other. Everyone around them acted like this was SOP.
Screaming at people seemed to be corporate policy. I had to undergo
a half hour diatribe (after a 36 hour day) about some piece of code I
didn't support or even understand, all the while trying not to say something
that could come back and bite me in the XXX.

Dan Mercer

:
: Pity, really, considering the repulsive mess that is the 8086
: instruction set.
:
: --
: André Majorel <URL:http://www.teaser.fr/~amajorel/>
: Conscience is what hurts when everything else feels so good.

red floyd

2004-09-02, 6:51 pm

Andre Majorel wrote:

> On 2004-08-30, Rich Teer <rich.teer@rite-group.com> wrote:
>
>
>
> Agreed, but... I read somewhere that designing the PC around the
> 68000 would have increased its price by 20% or 30%. I haven't
> found a detailed discussion of how they arrived at that figure,
> but I imagine that one of the factors is that 68000 code is not
> as compact since all addresses are 32-bit.
>
> Pity, really, considering the repulsive mess that is the 8086
> instruction set.
>

I think it had to do with the 8088 having an 8-bit external bus, while
the 68000 had a 16-bit external bus. The peripheral chips were cheaper.

Rich Teer

2004-09-02, 6:51 pm

On Tue, 31 Aug 2004, red floyd wrote:

> I think it had to do with the 8088 having an 8-bit external bus, while
> the 68000 had a 16-bit external bus. The peripheral chips were cheaper.

Perhaps, but there was also the 68008, which was a 68K with an
8-bit external bus.

I suspect IBM's bad CPU choice was driven by a somewhat dubious desire
for CP/M compatability.

--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming",
published in August 2004.

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

Hans Surst

2004-09-02, 6:51 pm

On Tue, 31 Aug 2004 16:52:58 GMT, Rich Teer <rich.teer@rite-group.com>
wrote:

> I suspect IBM's bad CPU choice was driven by a somewhat dubious desire
> for CP/M compatability.

The 8088 was in some way binary compatible to some older CPUs and it was
asm code compatible to some other older CPUs. So I guess the 8088 was
designed by intel to extent the 8080 and Z80 to 16bit Software. Intel had
a similar CPU to the 68000 this time (the 68K came a few years later). So
yes, to be in some way CP/M compatible wasn't a bad idea. A CPU with no
software has null speed.

BTW, AMD64 is the same stupid design as X86... just a bit extended, as it
allways got :-))

--
All my spammers die in horrible pains!