CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Why did not supports?

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
denkid



Joined: 17 Jan 2005
Posts: 10

View user's profile Send private message

Why did not supports?
PostPosted: Fri Jan 21, 2005 7:32 am     Reply with quote

Hello,

Why did not supports
Code:

char *p="ABCDEFG";


This is not standard ANSI C?..

My Version : CCS-C 3.190
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Fri Jan 21, 2005 7:49 am     Reply with quote

I think you are trying to do a pointer to a constant which is not allowed.

you can do this:
Code:

char buf[]="ABCDEFG";
char *p;

p=buf;
SherpaDoug



Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA

View user's profile Send private message

PostPosted: Fri Jan 21, 2005 8:28 am     Reply with quote

1) CCS C is not ANSI C. It is closer to Kernighan & Ritchie first edition C.
2) The main reason pointers to constants are not allowed is due to the Harvard architecture of the PIC processor, which keeps ROM space and RAM space seperate. Constants are stored in ROM space, which has a wider data width (12, 14, or 16 bits) than RAM space (8 bits) where pointers operate.
_________________
The search for better is endless. Instead simply find very good and get the job done.
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Fri Jan 21, 2005 8:58 am     Reply with quote

SherpaDoug wrote:
2) The main reason pointers to constants are not allowed is due to the Harvard architecture of the PIC processor, which keeps ROM space and RAM space seperate. Constants are stored in ROM space, which has a wider data width (12, 14, or 16 bits) than RAM space (8 bits) where pointers operate.


No offense, but that is a load of crap. The reason that I say that is the some of the other PIC C compilers support pointers to constants. Fact of the matter is that CCS just didn't do it. They could if they wanted to and I believe it will be in there soon enough. They didn't have pointers to functions, but now they do. It is only a matter of time.
Ttelmah
Guest







PostPosted: Fri Jan 21, 2005 9:45 am     Reply with quote

Mark wrote:
SherpaDoug wrote:
2) The main reason pointers to constants are not allowed is due to the Harvard architecture of the PIC processor, which keeps ROM space and RAM space seperate. Constants are stored in ROM space, which has a wider data width (12, 14, or 16 bits) than RAM space (8 bits) where pointers operate.


No offense, but that is a load of crap. The reason that I say that is the some of the other PIC C compilers support pointers to constants. Fact of the matter is that CCS just didn't do it. They could if they wanted to and I believe it will be in there soon enough. They didn't have pointers to functions, but now they do. It is only a matter of time.


In part, but with pointers to ROM, there is a cost. If you think of a typical large PIC, the RAM space is perhaps 1.5KB, while many now have ROM spaces of 64KB, or those supporting external memory, even more. If you allow pointers to ROM, then you force 'pointers' fo be a much larger value (an int16, will address every possible RAM address on ony current PIC, but with the ROM address spaces allowed on some chips, a pointer would need to grow to at least an int24). With this there would also be an overhead for pointer operations, of working out which memory area to access. Ideally, implementation would be in the form of an 'option', so that the extra overheads involved, do not have to apply where this feature is not needed.
Historically, the 'reason', was that it is basically impossible to implement ROM pointers on the early chips, it became simply possible, on the chips that implement the ability to read a byte from the memory (most of the flash chips), and except for the C syntax involved, the read_program_memory function, implements the required access operation. I must admit, it is suprising that this has not been offered as an option for these chips, and it may well apear in the future.

Best Wishes
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Fri Jan 21, 2005 9:51 am     Reply with quote

Quote:
but with the ROM address spaces allowed on some chips, a pointer would need to grow to at least an int24
You can specify the memory model which would dictate the size of the pointer. Also, this is only true for the constant pointer. RAM based pointers can still be 8 or 16 bit regardless of the size of the constant pointer.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Jan 21, 2005 10:16 am     Reply with quote

Mark, have you examined the ASM code in other compilers ?
Can you tell us how they make pointers to ROM for the PIC16 ?
Darren Rook



Joined: 06 Sep 2003
Posts: 287
Location: Milwaukee, WI

View user's profile Send private message Send e-mail

PostPosted: Fri Jan 21, 2005 11:44 am     Reply with quote

Mark wrote:
RAM based pointers can still be 8 or 16 bit regardless of the size of the constant pointer.


No.

Example:

Code:

  char *ptr;
  const char rom[]="CONSTANT IN ROM";
  char ram[]="CONSTANT IN RAM";

  ptr=rom;
  ptr=ram;


ptr will have to hold extra overhead to know if it's point to RAM or ROM. Also it will have to be an int32 value to hold the full 32 bit address for ROM. Probably a 32bit value with bit31 set if it's ROM, clear if RAM.

BTW - There are some undocumented typemod features you can use to get functionality very very close to pointers to ROM. So I don't think CCS is far away. If I have time later I will try to show some examples.


Last edited by Darren Rook on Fri Jan 21, 2005 12:38 pm; edited 1 time in total
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Fri Jan 21, 2005 12:08 pm     Reply with quote

Darren Rook wrote:
Mark wrote:
RAM based pointers can still be 8 or 16 bit regardless of the size of the constant pointer.


No.

Example:

Code:

  char *ptr;
  const char rom[]="CONSTANT IN ROM";
  const char ram[]="CONSTANT IN RAM";

  ptr=rom;
  ptr=ram;


ptr will have to hold extra overhead to know if it's point to RAM or ROM. Also it will have to be an int32 value to hold the full 32 bit address for ROM. Probably a 32bit value with bit31 set if it's ROM, clear if RAM.

BTW - There are some undocumented typemod features you can use to get functionality very very close to pointers to ROM. So I don't think CCS is far away. If I have time later I will try to show some examples.
[/quote]

As you put it, you would be right. But you are wrong. The compilers that support (at least the ones I use) wouldn't allow that. It has to be a pointer to a const. It is a differenct data type thus a different kind of pointer.
Code:

  const char *pointer;


For example with the HI-TECH you would get this warning:
Quote:

Warning[000] C:\HT-PIC\samples\picdem2\picdem2.c 30 : illegal conversion between pointer types


Last edited by Mark on Fri Jan 21, 2005 12:15 pm; edited 1 time in total
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Fri Jan 21, 2005 12:13 pm     Reply with quote

PCM programmer wrote:
Mark, have you examined the ASM code in other compilers ?
Can you tell us how they make pointers to ROM for the PIC16 ?


Hi-Tech uses the retlw approach. They simply have a routine they call. The high byte of the const pointer is loaded into what is referred to internally as the high byte of "code_ptr". The low byte is put into the W register and the internal routine is called. The W reg is then put into the code_ptr low byte. Tests are made on the high byte. The next action depends on how the upper 2 bits are set but basically the code_ptr is loaded into the PCL and the const is returned in the W reg and then acted upon.
Darren Rook



Joined: 06 Sep 2003
Posts: 287
Location: Milwaukee, WI

View user's profile Send private message Send e-mail

PostPosted: Fri Jan 21, 2005 12:43 pm     Reply with quote

Mark wrote:

As you put it, you would be right. But you are wrong. The compilers that support (at least the ones I use) wouldn't allow that. It has to be a pointer to a const. It is a differenct data type thus a different kind of pointer.
Code:

  const char *pointer;



I see what you mean - you are right I was wrong.
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Fri Jan 21, 2005 2:26 pm     Reply with quote

Darren Rook wrote:
Mark wrote:

As you put it, you would be right. But you are wrong. The compilers that support (at least the ones I use) wouldn't allow that. It has to be a pointer to a const. It is a differenct data type thus a different kind of pointer.
Code:

  const char *pointer;



I see what you mean - you are right I was wrong.


The C18 compiler requires you to use 'rom' in front of the declaration. It will also allow you to declare a pointer to a const and the pointer to the const can actually be stored in rom to conserve RAM. This comes in handy when doing menus and command parsers.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group