search for: rampointer

Displaying 7 results from an estimated 7 matches for "rampointer".

Did you mean: pa_pointer
2007 Sep 13
0
[LLVMdev] PointerTypes with AddressSpace
...in the spirit of C at all. C is very explicit (to a fault perhaps). > -- d) Conflicts at the function interface will spawn a new function > eg: > void inc(int *a){ > (*a)++; > } > void g(void){ > inc(romPointer); // this will spawn an f with rom pointer > inc(ramPointer); // this will spawn an f with ram pointer > } > > In the case of (2) we still need rom and ram qualifiers to declare > variables in the intended Address Space, however the impact on the > front > end will probably be reduced. > A combination of (1) and (2) would probably be...
2007 Sep 13
2
[LLVMdev] PointerTypes with AddressSpace
...in the spirit of C at all. C is very explicit (to a fault perhaps). > -- d) Conflicts at the function interface will spawn a new function > eg: > void inc(int *a){ > (*a)++; > } > void g(void){ > inc(romPointer); // this will spawn an f with rom pointer > inc(ramPointer); // this will spawn an f with ram pointer > } > > In the case of (2) we still need rom and ram qualifiers to declare > variables in the intended Address Space, however the impact on the > front > end will probably be reduced. > A combination of (1) and (2) would probably be...
2007 Sep 13
3
[LLVMdev] PointerTypes with AddressSpace
...void f(void){ generalPtr = romPtr; //some code generalPtr = ramPtr; // non resolvable conflict } -- d) Conflicts at the function interface will spawn a new function eg: void inc(int *a){ (*a)++; } void g(void){ inc(romPointer); // this will spawn an f with rom pointer inc(ramPointer); // this will spawn an f with ram pointer } In the case of (2) we still need rom and ram qualifiers to declare variables in the intended Address Space, however the impact on the front end will probably be reduced. A combination of (1) and (2) would probably be ideal. Regards, Ali. -----Ori...
2007 Sep 13
0
[LLVMdev] PointerTypes with AddressSpace
...ery explicit (to a fault perhaps). > >> -- d) Conflicts at the function interface will spawn a new function >> eg: >> void inc(int *a){ >> (*a)++; >> } >> void g(void){ >> inc(romPointer); // this will spawn an f with rom pointer >> inc(ramPointer); // this will spawn an f with ram pointer >> } >> >> In the case of (2) we still need rom and ram qualifiers to declare >> variables in the intended Address Space, however the impact on the >> front >> end will probably be reduced. >> A combination of (1)...
2007 Sep 14
2
[LLVMdev] Embedded C Language Extensions
...ery explicit (to a fault perhaps). > >> -- d) Conflicts at the function interface will spawn a new function >> eg: >> void inc(int *a){ >> (*a)++; >> } >> void g(void){ >> inc(romPointer); // this will spawn an f with rom pointer >> inc(ramPointer); // this will spawn an f with ram pointer >> } >> >> In the case of (2) we still need rom and ram qualifiers to declare >> variables in the intended Address Space, however the impact on the >> front >> end will probably be reduced. >> A combination of (1)...
2007 Sep 12
0
[LLVMdev] New to LLVM, Help needed
On Wed, 12 Sep 2007 Alireza.Moshtaghi at microchip.com wrote: > Thank you Chris, > I had the pointer size wrong. I fixed it and now it passes that point as > expected :) which takes me to a second question: cool > The processor that I am working on is 8-bit and has Harvard > architecture; this implies different pointer types (sizes) to objects in > data memory or program memory
2007 Sep 12
2
[LLVMdev] New to LLVM, Help needed
Thank you Chris, I had the pointer size wrong. I fixed it and now it passes that point as expected :) which takes me to a second question: The processor that I am working on is 8-bit and has Harvard architecture; this implies different pointer types (sizes) to objects in data memory or program memory (functions or data in program memory) At this moment, I am just using only one pointer size