These are not standard keywords. They are supported in some sdcc backends, but currently not for STM8.
Personally, in the software I wrote, I never encountered a use case for __data and __code.
__far would be nice to have, but is useful only for very few of the STM8 microncontrollers.
__near on STM8 might allow some minor hand-optimizing by the programmer for code size or speed, but is not a big deal either.
What would you want these keywords for?
Philipp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am making a LED moving message display (Multilingual). I need to put CG (character generator) code on code memory. The CG size may be 8 to 10 KB. So __code is very essential to me. For better size or speed I need to declare some variable at page0 of RAM (first 256 bytes). I think near can do this.
jags
Last edit: Jagadish Paul 2015-06-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
__near could place a variable in the first 256 B of RAM, if it was implemented. However, this would only speed up direct access (i.e. accessing a global variable, but not through a pointer). Access through a pointer might actually be slower: On the STM8, pointer accesses usually go through the 16-bit register x or y, so any 8-bit pointer would have to be zero-extended before use. This is quite different from e.g. the mcs51.
Philipp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, I still don't understand what advantage __code would provide here. If you want to be able to modify the table at runtime, it has to go into RAM. If you don't want to modify it a runtime, you can declare it as const, and it will go to the same place as your program code.
Philipp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, const should do all you might need or want from __code. In fact I don't see any way of implementing __ocde other than as a synonym for const. So I see no point in implementing __code.
__near on the other hand can be useful; but other optimizations and improvements are likely to yield bigger improvements than __near and do need less work from the user. So __near is something I want to implement in sdcc, but it is not among the most important items.
Philipp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually, __near does not provide a speed advantage at all: Looking at the STM8 CPU programming manual, accessing __near variables would take the same number of cycles as accessing other variables.So __near could only help a little with code size, not with speed.
Philipp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I currently think (but would need to look into the details more, to give a definite answer) __eeprom is useful and should be implemented. But considering that I'm currently quite busy with things other than sdcc, I most likely won't be able to do it anytime soon. Maybe someone else will.
Philipp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If pag0 is in the same memory space as normal ram then I would not recommend to treat near pointers any different from normal pointers. So no zero-extending at runtime.
If there is also no speed improvement for global/static near variables, but only a small size improvement, I don't think it's worth to implement it at all.
Finally on const: gcc seems to think that an auto const should live on the stack. I was totally surprised when I found that out. I'm glad we just always put it in code memory.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These are not standard keywords. They are supported in some sdcc backends, but currently not for STM8.
Personally, in the software I wrote, I never encountered a use case for __data and __code.
__far would be nice to have, but is useful only for very few of the STM8 microncontrollers.
__near on STM8 might allow some minor hand-optimizing by the programmer for code size or speed, but is not a big deal either.
What would you want these keywords for?
Philipp
I am making a LED moving message display (Multilingual). I need to put CG (character generator) code on code memory. The CG size may be 8 to 10 KB. So __code is very essential to me. For better size or speed I need to declare some variable at page0 of RAM (first 256 bytes). I think near can do this.
jags
Last edit: Jagadish Paul 2015-06-13
__near could place a variable in the first 256 B of RAM, if it was implemented. However, this would only speed up direct access (i.e. accessing a global variable, but not through a pointer). Access through a pointer might actually be slower: On the STM8, pointer accesses usually go through the 16-bit register x or y, so any 8-bit pointer would have to be zero-extended before use. This is quite different from e.g. the mcs51.
Philipp
Sorry, I still don't understand what advantage __code would provide here. If you want to be able to modify the table at runtime, it has to go into RAM. If you don't want to modify it a runtime, you can declare it as const, and it will go to the same place as your program code.
Philipp
Is there any way of implement of __near & __code.
I really need it.
Without __code I can't build my display app.
jags
Thanks Philipp.
you mean using const I can place variable or array at code memory. In this case _code does not has any sense.
can I use __at (0xxxxx) ?
How to implement of near?
jags
Yes, const should do all you might need or want from __code. In fact I don't see any way of implementing __ocde other than as a synonym for const. So I see no point in implementing __code.
__near on the other hand can be useful; but other optimizations and improvements are likely to yield bigger improvements than __near and do need less work from the user. So __near is something I want to implement in sdcc, but it is not among the most important items.
Philipp
Actually, __near does not provide a speed advantage at all: Looking at the STM8 CPU programming manual, accessing __near variables would take the same number of cycles as accessing other variables.So __near could only help a little with code size, not with speed.
Philipp
OK got it.
What about __eeprom ???
Do you have any plan to implement??
jags
I currently think (but would need to look into the details more, to give a definite answer) __eeprom is useful and should be implemented. But considering that I'm currently quite busy with things other than sdcc, I most likely won't be able to do it anytime soon. Maybe someone else will.
Philipp
If pag0 is in the same memory space as normal ram then I would not recommend to treat near pointers any different from normal pointers. So no zero-extending at runtime.
If there is also no speed improvement for global/static near variables, but only a small size improvement, I don't think it's worth to implement it at all.
Finally on const: gcc seems to think that an auto const should live on the stack. I was totally surprised when I found that out. I'm glad we just always put it in code memory.