Phooey on Portability
T-RELAY.ARPA>@brl-smoke.arpa
struct {
char byte;
int word;
long longword;
} *MEMORY;
main(){char mybyte = 6->byte;}
No sweat. Works like a charm daily. But what do I do on segmented memory
systems like the PC?
main(){char mybyte = 0:6->byte;}
Not likely. So much of the squirming about lvalues and chars and the like
comes from both wanting to be memory system independent and close the metal.
Why don't we just say that every compiler writer should include a section
in the manual called "Memory Model" wherein the following things are defined?
I personally want to snuggie right up the memory system in my C programs.
That's why I chose C! I really have plenty to worry about besides machines
I'm NOT trying to program. I guess what I'm saying is that until we can
create well-engineered, reliable code for one machine why are we wasting
our time worrrying about doing it for all machines at once? In other words,
portability is mostly a red herring. Good code on one machine beats
bad code on many machines every time.
"Executable requirements wouldn't."
Gregory Smith
>I'd like to get at the byte stored in memory location 6. So I just
>
>struct {
> char byte;
> int word;
> long longword;
>} *MEMORY;
>
>main(){char mybyte = 6->byte;}
>
>No sweat. Works like a charm daily.
wrong, Wrong, WRONG! I won't try to correct the weirdnesses above since
I can't really see what you're doing. What are 'word' and 'longword' for ???
It's done like this:
mybyte = * ( char * ) 6;
> But what do I do on segmented memory
>systems like the PC?
>
>main(){char mybyte = 0:6->byte;}
Easy. *( char * ) 6.
On a hideous machine like the 8088, (char *)6 *should* yield a pointer
to the absolute address 6, in whatever pointer format is used in
the 'memory model'(barf) you are using. Thus *(char *)6 *should* be
an lvalue which is stored at that absolute address. Whether this happens or
not is up to whichever masochist wrote the compiler.
>
>So much of the squirming about lvalues and chars and the like
>comes from both wanting to be memory system independent and close the metal.
>Why don't we just say that every compiler writer should include a section
>in the manual called "Memory Model" wherein the following things are defined?
Yes. This section should list the things that *will* work on that
implementation, but which you shouldn't use ( unless you are writing
device drivers ) because they won't port. It should then
give you equivalent portable methods.
>I personally want to snuggie right up the memory system in my C programs.
Do you want to play with segment registers in your C code ( shudder )?
>That's why I chose C! I really have plenty to worry about besides machines
>I'm NOT trying to program. I guess what I'm saying is that until we can
>create well-engineered, reliable code for one machine why are we wasting
>our time worrrying about doing it for all machines at once?
Because it's not that much harder, once you get used to it.
Who says we can't create reliable, well-engineered code? I have.
It takes less *extra* time to make something portable than it takes
to go through and hack it up if you do have to port it. It does happen.
>In other words,
>portability is mostly a red herring. Good code on one machine beats
>bad code on many machines every time.
>
Great! so why not write good code which is portable? It is mostly the
'messy' stuff that causes portability problems anyway.
--
----------------------------------------------------------------------
Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
Have vAX, will hack...