Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/jerdew5/orbworks.com/forum/includes/bbcode.php on line 472
[phpBB Debug] PHP Notice: in file /includes/functions.php on line 3368: Cannot modify header information - headers already sent by (output started at /includes/bbcode.php:472)
[phpBB Debug] PHP Notice: in file /includes/functions.php on line 3370: Cannot modify header information - headers already sent by (output started at /includes/bbcode.php:472)
[phpBB Debug] PHP Notice: in file /includes/functions.php on line 3371: Cannot modify header information - headers already sent by (output started at /includes/bbcode.php:472)
[phpBB Debug] PHP Notice: in file /includes/functions.php on line 3372: Cannot modify header information - headers already sent by (output started at /includes/bbcode.php:472)
OrbWorks Community Forum • View topic - Some general language questions

Some general language questions

Discuss topics that apply across the products, such as the PocketC language, or development in general

Postby Josh on Sun Aug 18, 2002 11:33 am

Greetings to you all,

before I start my silly questions, let me introduce myself a bit; I'm an old time C programmer (way back in '76 C and I started our love/hate relationship). C++ was a revelation to me somehere in '84 and the last seven years I've studied (more or less) all of the Java stuff (with its way too many classes and frameworks for one old sod like me to remember by head).

Yesterday I purchased a copy of PocketC, installed it on my Jornada 728 (bought the day before) and started carousing and pirating the net for language and library reference documentation, i.e. I wanted a PocketC equivalent of, say, the C++ ARM (Annotated Reference Manual).

This brought me here in this forum and, after reading most of its messages, I came to realize that there is no such thing as an 'ARM' for PocketC ... This leaves me with a couple of questions -- could some kind soul please explain to me how an allocated array of, say n, structures could/should be manipulated? e.g.

<pre id=code><font face=courier size=2 id=code>
struct foo { int bar; string baz; }
</font id=code></pre id=code>

1: how does one allocate n struct foo elements?
2: how does one access a member of an individual element?

As I understood from the (ahem) not so complete language reference documents, arrays (including allocated ones) are passed by address (or by 'reference' as you wish) to functions. Here's my third questions:

3: What would be the formal parameter specification of an allocated array of 'struct foo's?
4: what is the syntax of the declaration of a reference paramter?

This brings me to another (set of) question(s). As I understood, the 'string' type is a first class citizen in the PocketC language. They are, for example, created behind your back by functions such as 'gets(string prompt)' and I'm almost sure that they are destroyed again whenever a string typed variable is assigned another value, e.g.

<pre id=code><font face=courier size=2 id=code>
string s= gets("Gimme a foo");
s= gets("Gimme a bar"); /* "foo" must be removed ... */
</font id=code></pre id=code>

Now what happens if the following code snippet is executed:

<pre id=code><font face=courier size=2 id=code>
pointer p= malloc(2);

settype(p, 2, 's'); /* they're both strings */

p[0]= gets("Gimme a foo");
p[1]= gets("Gimme a bar");

free(p);
</font id=code></pre id=code>

question number five:

5: Now what happens to the memory taking up the two (allocated?) strings? Does the PocketC runtime system take care of that by using some form of (un)available string pools?

And finally, here's my last question:

6: does an 'ARM' like document exist for the PocketC language?

I apologize for asking all these questions, but carousing and pirating the net didn't bring me much further than this fine place.

thanks in advance and kind regards,

Josh

Two things are omnipresent in this universe: oxygen and stupidity
-- Frank Zappa
Two things are omnipresent in this universe: oxygen and stupidity
-- Frank Zappa
Josh
 
Posts: 6
Joined: Sun Aug 18, 2002 10:56 am
Location: Netherlands

Postby guy on Mon Aug 19, 2002 7:24 am

Hi,

1. static: struct foo jim[100] ;
dynamic: p = malloc(100 * 2) ; // Assuming 100 elements of 2 fields each
2. static: i = jim[65].bar ;
dynamic: i = p[65 + 0] ; // Assuming bar is first element in struct
3. Aahaha haha hahaha! You lose. There is a kludge workaround however,as you can see above.
4. myfunction(struct foo & jim) {
5. The strings are deallocated and returned to from wherever PocketC gathers string space.
6. Partially. Try http://www.orbworks.com/wince/doc/index.html

The documentation doesn't cover all of the language features, and it's wrong in some places.

The Knowledge Base section of this board includes some of the missing information (macros, compiler pragmas).

I haven't seen any information on the PocketC support of reference variables or structs. Structs are like real C structs, but you can't have a pointer to a struct (you can use a reference variable). Reference variables look like C++ reference variables.

The best bet is to ask a question in the forum and someone will answer it for you.

If you take the address of a struct you can then access the elements as an array. This gives you a method of passing structs to a function as a pointer. If you allocate memory with one element per struct element, then set the types correctly, then you have a dynamically allocated object that looks exacly like a struct to PocketC.




Guy
[url]mailto:pcform@pcform.net[/url]
http://www.pcform.net
PocketC CE API interface: http://www.networkdynamics.net/PCForm.html#library
PCForm and CE API forum: http://www.networkdynamics.net/forum
Guy
[url]mailto:pcform@pcform.net[/url]
http://www.pcform.net
PocketC CE API interface: http://www.networkdynamics.net/PCForm.html#library
PCForm and CE API forum: http://www.networkdynamics.net/forum
guy
 
Posts: 879
Joined: Thu Dec 07, 2000 8:58 am
Location: United Kingdom

Postby Josh on Mon Aug 19, 2002 9:20 am

guy,

thank you very much for your very informative answers; I really appreciate it. Allow me to elaborate a bit on one question/answer though:

<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
5. The strings are deallocated and returned to from wherever PocketC <hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>

If this is true (and I believe your word for it), both the settype() and memcpy() functions must be quite expensive functions then, i.e. (thinking out loud) before setting the type of a memory 'cell', the old type has to be checked and if it happens to be a string 's', the string must be de-allocated or at least some reference counter has to be decremented. All other scenarios would cause memory leaks ...

These strings must be reference counted, otherwise function memcpy() would have to make deep copies in order to avoid multiple references to one single string ...

Am I way off, thinking that PocketC is still under heavy development? The 'struct' notion and reference variables versus pointers, are IMHO not completely implemented (yet) ... i.e. the four basic data types are all 'tagged' by a type identification; that's the way 'int i; pointer p; p= &i; *p= 42;' is able to do what it has to do. Not so with pointers to structs; structs don't have a type tag; even more, this type tag would be too complicated to be represented by a simple single character ...

kind regards,

Josh

Two things are omnipresent in this universe: oxygen and stupidity
-- Frank Zappa
Two things are omnipresent in this universe: oxygen and stupidity
-- Frank Zappa
Josh
 
Posts: 6
Joined: Sun Aug 18, 2002 10:56 am
Location: Netherlands

Postby guy on Mon Aug 19, 2002 9:55 am

Internally a PocketC variable is represented by a C++ class, the class contains a union of all three numeric types (int, char and float - actually double) and a string class.

The string class has it's own allocation managment. As far as I'm aware it handles reference counting.

The class has a SetVal() member function which is overloaded for each type, the correct SetVal() is called depending on the source and destination types. This handles everything that you need as far as memory allocation and deallocation is concerned.

I don't know what happens if you use settype() to change a string to something else. I suspect that the memory used by the string becomes inaccessible until you settype() the PocketC variable back to what it was before. I don't know whether memory is correctly deallocated if you change a malloced string to another type and then free it. I can't think of any legitimate situation in which this would occur.

Pointers have always been ints. They are ints in most implementations of C. At run time the interpreter really doesn't care what you called the data type at compile time. It's just a number that's being used to reference "memory" (PocketC memory).

structs are simply contiguous PocketC memory variables. The pointer access to structs is complicated because the original language definition had a single "pointer" type that referenced polymorphic objects. If you just declare something as a pointer then there is no very simple way to then handle syntax like p->field. Particularly if several different structs have fields of the same name with different offsets.

A compiler can work out the type of a pointer (or any other variable) from the context in which it is used. PocketC doesn't so this.

struct was introduced into PocketC V3 in a partial way. Kevin is threatening to remove it from PocketC V4. For PocketC V2 I had to write a library to implement structs via allocated memory in PocketC just so I could handle dynamic data structures.

PocketC for Palm has always been under development. PocketC for CE stays much the same for a long time, then gets reimplemented from scratch for the next version. V3 has been around for a long time.







Guy
[url]mailto:pcform@pcform.net[/url]
http://www.pcform.net
PocketC CE API interface: http://www.networkdynamics.net/PCForm.html#library
PCForm and CE API forum: http://www.networkdynamics.net/forum
Guy
[url]mailto:pcform@pcform.net[/url]
http://www.pcform.net
PocketC CE API interface: http://www.networkdynamics.net/PCForm.html#library
PCForm and CE API forum: http://www.networkdynamics.net/forum
guy
 
Posts: 879
Joined: Thu Dec 07, 2000 8:58 am
Location: United Kingdom

Postby Josh on Mon Aug 19, 2002 11:54 am

Guy,

thank you again for your prompt and accurate reply. Here are some of my comments:

<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
Internally a PocketC variable is represented by a C++ class, the class contains a union of all three numeric types (int, char and float - actually double) and a string class.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>

My oh my oh my ... so any 'cell' of memory takes up an instance (or pointer to such an instance) of:

<pre id=code><font face=courier size=2 id=code>
class Cell {
private:
union {
char c;
int i;
double d;
string s;
} value;
char type;
public:
void settype(char type);
void setVal(char c);
void setVal(int);
/* etc */
};

// the PocketC notion of 'memory'
Cell* memory;
</font id=code></pre id=code>

That would be an awful waste of space for just storing a char or an int, wouldn't it?

<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
The string class has it's own allocation managment. As far as I'm aware it handles reference counting.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>

If the std::string class is used, yes, reference counting (lazy copying) is used.

<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
The class has a SetVal() member function which is overloaded for each type, the correct SetVal() is called depending on the source and destination types. This handles everything that you need as far as memory allocation and deallocation is concerned.

I don't know what happens if you use settype() to change a string to something else. I suspect that the memory used by the string becomes inaccessible until you settype() the PocketC variable back to what it was before. I don't know whether memory is correctly deallocated if you change a malloced string to another type and then free it. I can't think of any legitimate situation in which this would occur.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>

Well, if it's been implemented correctly, the memcpy() and settype() functions would/should all check if an explicit destructor call is needed when a string value is being converted to some other type.

<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
Pointers have always been ints. They are ints in most implementations of C. At run time the interpreter really doesn't care what you called the data type at compile time. It's just a number that's being used to reference "memory" (PocketC memory).
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>

Don't get me started on ints being pointers and vice versa <img src=icon_smile_wink.gif border=0 align=middle> Both the ANSI/ISO C89 and C99 standards elaborate on this exquisite little thingy. Years ago, when VAXen ruled the world and words were words and pointers fitted into a word, this were true, but nowadays, pointers are not ints, neither vice versa ...

<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
structs are simply contiguous PocketC memory variables. The pointer access to structs is complicated because the original language definition had a single "pointer" type that referenced polymorphic objects. If you just declare something as a pointer then there is no very simple way to then handle syntax like p->field. Particularly if several different structs have fields of the same name with different offsets.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>

That's correct; and that was what I was refering to in my previous reply: structs carry no type information of their own; it would be impossible to register all the types of the members of a structure using just a single char (see the code block above).

<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
A compiler can work out the type of a pointer (or any other variable) from the context in which it is used. PocketC doesn't so this.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>

Have you ever seen a simple RTTI (Run Time Type Information) class in C++? It's a total mess. Java's introspection/reflection is far superior here.

<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
struct was introduced into PocketC V3 in a partial way. Kevin is threatening to remove it from PocketC V4. For PocketC V2 I had to write a library to implement structs via allocated memory in PocketC just so I could handle dynamic data structures.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>

*threatening*? IMVHO that would be silly. It scares a user base away from the language and it doesn't quite really make one look like a 'friendly person', would it?

<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
PocketC for Palm has always been under development. PocketC for CE stays much the same for a long time, then gets reimplemented from scratch for the next version. V3 has been around for a long time.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>

Yes, I've read your sentiments regarding delaying the release of V4, because of the remaining bugs in V3 need fixing desparately ... I agree with you.

I think I'll start carousing and pirating the net again for some classes.zip file containing the javac compiler and see if that chaiVM om my Jornada can handle it ... I really would like to have available a stable 'on the road' programming environment for my new toy <img src=icon_smile_wink.gif border=0 align=middle>

Again, I really appreciate your prompt and accurate replies; Thank you.

kind regards,

Josh

Two things are omnipresent in this universe: oxygen and stupidity
-- Frank Zappa

Edited by - Josh on 08/19/2002 07:28:37
Two things are omnipresent in this universe: oxygen and stupidity
-- Frank Zappa
Josh
 
Posts: 6
Joined: Sun Aug 18, 2002 10:56 am
Location: Netherlands

Postby guy on Mon Aug 19, 2002 4:10 pm

Hmm. Serves me right for trying to simplify things too much.

Yes, PocketC variables take up a <b>huge</b> amount of room each. Every operation is slow because the runtime has to do type checking and conversion in every expression. Even obviously redundant operations take time. Casts are executed. i = (int) 1 is slower to run than i = 1.

The string uses a ustring class (unicode string) which does everything you would expect.

When I talked about a compiler being able to work out the type of a variable from context, I meant the <b>compiler</b> not the runtime. Given a variable of type pointer, an assignment to it should be all that is required in order for the compiler to know what it is a pointer to. Providing the usage is consistent then the compiler then knows how to translate p->field type syntax.

I forget the exact rules on the effect of casting pointers into ints and back again. I'll have to go and look it up. Unfortunately someone has stolen my copy of K&R (and someone had the first one from years back with the black C instead of the blue C).

When VAXen ruled the world you couldn't get a pointer into a WORD. You could only get one into a LONG. Our VAX still pretty much rules the office and we hardly ever have to top it up with more coal. (Off topic, but it's nice to see that Microsoft have <i>nearly</i> got an operating system as good as VMS now).

As far a struct support in V4 is concerned, Kevin is apparently porting the Palm version of PocketC V4 to CE, and the Palm version doesn't have structs. Kevin added them to the CE version for V3 after an amount of prodding. I am <b><i><u>VERY</u></i></b> concerned about compatibility in V4. I don't want to go from a good, but slow and slightly buggy V3 to a new, incompatible and buggy V4.



Guy
[url]mailto:pcform@pcform.net[/url]
http://www.pcform.net
PocketC CE API interface: http://www.networkdynamics.net/PCForm.html#library
PCForm and CE API forum: http://www.networkdynamics.net/forum
Guy
[url]mailto:pcform@pcform.net[/url]
http://www.pcform.net
PocketC CE API interface: http://www.networkdynamics.net/PCForm.html#library
PCForm and CE API forum: http://www.networkdynamics.net/forum
guy
 
Posts: 879
Joined: Thu Dec 07, 2000 8:58 am
Location: United Kingdom

Postby Josh on Mon Aug 19, 2002 6:37 pm

Guy,

thanks again for your elaborate replies. Below you'll find my remarks ...

<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
Yes, PocketC variables take up a <b>huge</b> amount of room each. Every operation is slow because the runtime has to do type checking and conversion in every expression. Even obviously redundant operations take time. Casts are executed. i = (int) 1 is slower to run than i = 1.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>

My oh my, ... runtime casts, where compile time casts would have sufficed; isn't it a valley of tears we live in? <img src=icon_smile_wink.gif border=0 align=middle>

<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
The string uses a ustring class (unicode string) which does everything you would expect.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>

That's cute. Does it convert between ordinary (ASCII) stream stuff and 'rich' (ahem) unicode stuff behind your back? i.e. does it do UTF8 trickery?

<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
When I talked about a compiler being able to work out the type of a variable from context, I meant the <b>compiler</b> not the runtime. Given a variable of type pointer, an assignment to it should be all that is required in order for the compiler to know what it is a pointer to. Providing the usage is consistent then the compiler then knows how to translate p->field type syntax.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>

Now we're entering the religious war area of compile time type checking and runtime type checking, the Javanians against the Smalltalkonists ... both have their advantages, both have their culprits but one thing is for sure: it's one way or the other, the PocketC 'in between' way doesn't apply for extensibility here. Even the (typeless) 'pointer' concept is not gonna make it if no RTTI mechanism is involved (besides the simple char, int, float, string stuff).

<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
I forget the exact rules on the effect of casting pointers into ints and back again. I'll have to go and look it up. Unfortunately someone has stolen my copy of K&R (and someone had the first one from years back with the black C instead of the blue C).
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>

These villains shoud have their heads nailed to the floor! <img src=icon_smile_wink.gif border=0 align=middle>

<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
When VAXen ruled the world you couldn't get a pointer into a WORD. You could only get one into a LONG.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>

You've got me there (I'm an old sod, please be gentle with me) a pointer fitted in a DWORD (a long) and that was all that was needed; ah, those were the days ...

<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
As far a struct support in V4 is concerned, Kevin is apparently porting the Palm version of PocketC V4 to CE, and the Palm version doesn't have structs. Kevin added them to the CE version for V3 after an amount of prodding. I am <b><i><u>VERY</u></i></b> concerned about compatibility in V4. I don't want to go from a good, but slow and slightly buggy V3 toa new, incompatible and buggy V4.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>

I know next to nothing about WinCE or Palm stuff (what's that spell?) or whatever, you know quite a lot about this stuff and (IMHO) have quite a thorough understanding about the computational language aspects. I happen to know quite a lot about the latter, i.e. parser generators, hand written parsers and code generators, lexical analyzers, risc-like and (application oriented) cisc-like code generators and interpreters (they call them VMs nowadays, just for marketing purposes) thereof ... including 'complete' semantics of languages (that's about those darn pointer/reference thingies that don't propagate whatever they're pointing to, amongst others).

Maybe a little synergy could result in some fun? *wink wink nudge nudge* have a small project started? I love to have complete runtime type checking (and I mean *complete* checking here), I'd love to see a little language with SmallTalk like capabilities, including the syntactical simplicity of the C/PocketC langauge; I do have quite some blue-prints ready for a 'not so standardized market' such as the wince/palm market ... but not let's carried away. What do you think?


kind regards,

Josh



Two things are omnipresent in this universe: oxygen and stupidity
-- Frank Zappa
Two things are omnipresent in this universe: oxygen and stupidity
-- Frank Zappa
Josh
 
Posts: 6
Joined: Sun Aug 18, 2002 10:56 am
Location: Netherlands

Postby guy on Tue Aug 20, 2002 9:21 am

I have a CE C(and_a_bit) compiler project that I keep putting on the back burner every time it looks like Kevin is going to do something to PocketC. It currently just parses stuff (lex, yacc and a little bit of C) and I really ought to start bolting on the other bits.

The chief problem with PocketC is the speed. I'd like to remove as much run-time type thrashing as possible. This only needs marginal intelligence in the compiler. I intend something compatible with PocketC except for its memory and pointer stuff. What I do with that is currently undefined. Maybe I'll just have a type that looks a bit like a PocketC variable. I'd like to have user type support, but that's a later consideration. I just want something that PocketC users can use on their CE device without having to rewrite all their code. Ideally I just want Kevin to release V4 with total compatibility with V3, extra speed and fewer bugs. Then I can just go to the pub instead.

I like the idea of an interpreted binary, simply because it's easier to deal with multiple targets, it has simplified distribution and produces smaller downloads (1 target file rather than about 13). The problem with an interpreter (or VM if you like) is that no matter how clean the interpreter you will still mash the processor pipeline. I have an interpreter design with very low overhead per actual machine instruction but it will still run much slower than real binary because it leaps all over the place. Perhaps in-place final translation is the answer (like CEF).

Any compiler I write has to be able to compile itself. The result has to compile user programs with reasonable speed (even if that's not the thing that is distributed to users). The reason that I wrote PCForm in PocketC was that it seemed pointless to write a support tool for a language in anything other than the language itself (the extreme masochism viewpoint in this case).

I have other projects in the pipeline, but I suspect that the pipeline has got rather blocked and diverted. I'm still updating the Windows CE API interface DLL even though I'm led to believe that PocketC V4 will call native code libraries in a completely different way to V3. I'll have to rewrite rather a lot I suspect. However V4 is apparently going to have a different event system to V3, so I'll have to modify PCForm as well. Perhaps I should just give it all up and become a ski instructor.






Guy
[url]mailto:pcform@pcform.net[/url]
http://www.pcform.net
PocketC CE API interface: http://www.networkdynamics.net/PCForm.html#library
PCForm and CE API forum: http://www.networkdynamics.net/forum
Guy
[url]mailto:pcform@pcform.net[/url]
http://www.pcform.net
PocketC CE API interface: http://www.networkdynamics.net/PCForm.html#library
PCForm and CE API forum: http://www.networkdynamics.net/forum
guy
 
Posts: 879
Joined: Thu Dec 07, 2000 8:58 am
Location: United Kingdom


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 0 guests

cron