home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / dsp / 3122 < prev    next >
Encoding:
Text File  |  1993-01-28  |  3.3 KB  |  68 lines
  1. Xref: sparky comp.dsp:3122 comp.lang.c:20312
  2. Newsgroups: comp.dsp,comp.lang.c
  3. Path: sparky!uunet!taumet!steve
  4. From: steve@taumet.com (Steve Clamage)
  5. Subject: Re: Is this a Legal Way to Access a Specific Address?
  6. Message-ID: <1993Jan28.172632.27400@taumet.com>
  7. Keywords: DSP, C, ANSI, Fixed RAM
  8. Organization: TauMetric Corporation
  9. References: <1993Jan24.171455.9451@bilver.uucp> <1k1pa3INNnl@elroy.jpl.nasa.gov> <1993Jan26.170719.22680@taumet.com> <1k7gk1INNooj@elroy.jpl.nasa.gov>
  10. Date: Thu, 28 Jan 1993 17:26:32 GMT
  11. Lines: 55
  12.  
  13. alan@elroy.Jpl.Nasa.Gov (Alan S. Mazer) writes:
  14.  
  15. >>>>We're programming a device that has a RAM cache at address 809800H.
  16. >>>>Is it legal to address this memory in C as follows?
  17. >>>>#define ON_CHIP 0x809800
  18. >>>>...
  19. >>>>   float *oc_ptr = (float *) ON_CHIP;
  20. ...
  21. >>In all such cases, an integer *value* is being cast to a pointer type.
  22. >>There are no literal pointer constants (except the null pointer) in C.
  23. >>The results of casting an integer value to a pointer type are
  24. >>implementation-defined and not portable.
  25.  
  26. >Okay, I'll agree with this.  But the net effect is the same.  If the constant
  27. >fits in one of those types (if it doesn't we'll get a compile-time error),
  28. >then the value can be usefully assigned to a pointer variable and used.  Note
  29. >that this code obviously is unportable to begin with.  We're writing to a
  30. >specific location in memory.  The danger in mixing pointers and ints is that
  31. >either may be too short to hold the other.  In this case, assuming the poster
  32. >knows what he's doing and isn't addressing outside his memory space, it's a
  33. >moot point.  If pointers are too small to hold the address specified, he
  34. >doesn't know what he's doing.  If they're not, then it works fine and there's
  35. >no ambiguity.  In short, there is still no problem that I can see.
  36.  
  37. The problem is that you have no assurance that the compiler expects to
  38. see machine addresses expressed as simple integers.  Compilers commonly
  39. allow that but are not required to.  On a segmented or otherwise
  40. complex architecture, an address might need to be broken into several
  41. parts, and a simple integer value might not have the results you expect.
  42.  
  43. Just because the programmer thinks of the absolute machine address as
  44. 0x809800 does not mean that the compiler will recognize the address
  45. when represented that way.  You have to read the compiler manual to
  46. find out how machine addresses should be expressed.
  47.  
  48. Even on as common a machine as a PC I may have to jump through a few
  49. more hoops to represent an address properly depending on the memory model.
  50. For example, suppose I want to reference 1 byte at absolute address
  51. 0x1234.  If I naively write
  52.     char *p = 0x1234;
  53. it might point to the byte in my global data segment at offset 0x1234
  54. rather than to absolute address 0x1234.  I need instead to do this:
  55.     char far *p = MK_FP(0, 0x1234);
  56. where MK_FP is a compiler-supplied macro which makes a far pointer out
  57. of a segment and offset.  This isn't portable to any other system, but
  58. the naive first attempt won't always work on a PC.
  59.  
  60. If I am programming on a Unix system, I can't get to absolute machine
  61. addresses this way at all.  Every program address is a virtual address,
  62. and I can't predict where the physical address will be.  I have to go
  63. via the memory-mapping system to get to a machine address, and the
  64. details vary with the flavor of Unix.
  65. -- 
  66.  
  67. Steve Clamage, TauMetric Corp, steve@taumet.com
  68.