Displaying 7 results from an estimated 7 matches for "rompointer".
Did you mean:
rampointer
2007 Sep 13
0
[LLVMdev] PointerTypes with AddressSpace
...ul error reports etc).
Type inference is very nice, but it is not 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 probab...
2007 Sep 13
2
[LLVMdev] PointerTypes with AddressSpace
...ul error reports etc).
Type inference is very nice, but it is not 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 probab...
2007 Sep 13
3
[LLVMdev] PointerTypes with AddressSpace
...unctions are not resolvable and should generate
diagnostic.
eg:
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...
2007 Sep 13
0
[LLVMdev] PointerTypes with AddressSpace
...nce is very nice, but it is not 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
>> fron...
2007 Sep 14
2
[LLVMdev] Embedded C Language Extensions
...nce is very nice, but it is not 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
>> fron...
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