[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The Internet-enabled Contiki Desktop OS



On Tue, 11 Mar 2003 18:59:54 +0000, Martijn van Buul wrote:
>> Now *that* would be quite nice; it would make Contiki every a few
>> years older :-) When was the PDP-11 released? 1975?
> 
> The PDP-11/20 and 11/15 saw their first light in 1970. The last model in
> 1990...

Wow... would it be possible to squeeze something like Contiki into the
11/20 or the 11/15?

>> How much work would it be to convert the existing ANSI C code to K&R?
> 
> I don't know, I haven't taken a good look at the sourcecode, yet. There
> are some annoying features about K&R which introduces possible problems in
> combination with the platform, though. The PDP-11 is a 16-bit platform;
> ints are therefore 16-bits too. If a program assumes that ints are 32 bits,
> there might be issues. Even worse, if a program assumes that some datatypes
> are issues, there might be problems, since K&R doesn't do automatical 
> typecasts.

Ok. That would probably not be any problem as far as Contiki is
concerned. The only assumption Contiki (or rather, uIP) places on the
C types is that there are 8-bit and 16-bit types - does the PDP-11 C
compiler have a 8-bit datatype? If not, uIP will not work.

> For instance, the seemingly perfectly valid
> 
>     fseek(file_descriptor,0,SEEK_SET);
> 
> goes terribly wrong - but you won't get any warning or error from that. It'll
> just bomb out during runtime. Instead, it should have been
> 
>     fseek(file_descriptor,0L,SEEK_SET);
> 
> In other words, "it compiles" is not the same as "it works", to put it 
> mildly :(

Ok... that may be a problem. Does gcc notice problems of this kind
when run with -pedantic or similar options?

> A common practice (and I think BSD's __P() does something like that) is
> to make your prototypes look like
> 
> int main PROTO( (int argc, char *argv[] ) );
> 
> with PROTO(x) a macro, defined as
> 
> #define PROTO (x)  x
> 
> on ANSI-systems, and as
> 
> #define PROTO (x)  ()
>
> on K&R systems.

Yep, that's how the BSD __P macro works as well.

>> Perhaps several __P1(), __P2(), etc., could be defined, and these could
>> automatically choose the correct "preamble" type. 
> 
> Similiarly, for the function definition, you could make your definition
> look like
> 
> int main DECL2( int, argc, char **, argv)
> 
> with DECL2 being defined as
> 
> #define DECL2 (t1,v1,t2,v2)  (t1 v1, t2 v2)
> 
> on ANSI systems, and
> 
> #define DECL2 (t1,v1,t2,v2) (v1 v2) t1 v1; t2 v2;
> 
> on K&R systems.

Yes, that's exactly what I was thinking about :-)

> Things get particulary annoying if you have const directives, though :-/

Ok, I assume there are differences in the ANSI and K&R const semantics?

> I'll take a peek at the code RSN.

Great, it would be highly appreciated!

/adam
-- 
Adam Dunkels - http://dunkels.com/adam/