🚀 go-pugleaf

In article <5225@brl-smoke.ARPA> T-RELAY.ARPA>@brl-smoke.ARPA writes:
>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...