Le Mon, 12 Jun 2006 16:29:26 +0200, Colin Collin Paul Gloster a &eacute;crit&nbsp;:

> On Sat, 10 Jun 2006, Michel Catudal wrote:
> 
> "[..]
> 
> If you design with a PIC you will prefer a C Compiler, CCS does a good
> one [..]"
> 
> Though ANSI/ISO C compliance is not something one expects in a 
> microcontroller, I had portable ISO C code compiled with various compilers 
> on various desktops and workstations. Trying to get CCS's C compiler to 
> work with it was a struggle I never succeeded in, though it was possible 
> after fewer modifications than with CCS to compile it with SDCC for the 
> 8051 (though I admit in that case, SDCC's resultant object code was too 
> large for 64KB).

I've used that compiler for a sunroof controller with a pic and it did
a good job. It was not ansi compliant but well done for that processor.
The only issue was with the debugging as I had to keep in mind that
it replaced routine calls with jumps. That processor is not meant
at all for C and CCS did a very good job and managed to do good
optimized code.
I used IAR when I moved to the AVR.

-- 
Tired of Microsoft's rebootive multitasking?
then it's time to upgrade to Linux.
http://home.comcast.net/~mcatudal
We are the Cybernetic Entomology Experts

On Sat, 10 Jun 2006, Michel Catudal wrote:

"[..]

If you design with a PIC you will prefer a C Compiler, CCS does a good
one [..]"

Though ANSI/ISO C compliance is not something one expects in a 
microcontroller, I had portable ISO C code compiled with various compilers 
on various desktops and workstations. Trying to get CCS's C compiler to 
work with it was a struggle I never succeeded in, though it was possible 
after fewer modifications than with CCS to compile it with SDCC for the 
8051 (though I admit in that case, SDCC's resultant object code was too 
large for 64KB).

Chris Hills wrote:
> In article <1149974739.342327.46730@f6g2000cwb.googlegroups.com>, toby
> <toby@telegraphics.com.au> writes
> 
>>Alex Colvin wrote:
>>
>>>>Since there is a thread on "C friendly" architectures, I thought it
>>>>might be interested to find out what sort of horrible architectures
>>>>compiler writers actually managed to create a C compiler for.
>>>
>>>There was an early C compiler for the GE 635, which had (36-bit) word
>>>addressing. Characters (6-bit) and bytes (9-bit) could be addressed only
>>>via extra indirection words. Where an ordinary pointer fit in 18 bits and
>>>could be in a register, byte or character pointers needed 36 and could
>>>only be in memory.
>>
>>I thought someone else would mention it by now, but another notorious
>>example is the word-addressed DG Nova, which required a separate
>>pointer format to address bytes. C compilers existed for this
>>architecture; 
> 
> 
> 
> I had to program that thing in Interpreted BASIC.... It ran the whole
> company!

The Novas were a great step forward from the previous one, the Digital
PDP-8. The history of Novas is tied tightly with PDP-8 and PDP-11.
The Nova is what was initially thought to become a PDP-11, but the
designers spun off Digital and set up an own company.

IIRC, the Novas are older than the C language, which was initially
set up on a PDP-11.

The idea of addressing everything as bytes was new in the minicomputer
world with the PDP-11, although on the mainframe side it was already
used in the IBM S/360.

-- 

Tauno Voipio
tauno voipio (at) iki fi

Chris Hills wrote:
> In article <1149974739.342327.46730@f6g2000cwb.googlegroups.com>, toby
> <toby@telegraphics.com.au> writes
> >Alex Colvin wrote:
> >> >Since there is a thread on "C friendly" architectures, I thought it
> >> >might be interested to find out what sort of horrible architectures
> >> >compiler writers actually managed to create a C compiler for.
> >>
> >> There was an early C compiler for the GE 635, which had (36-bit) word
> >> addressing. Characters (6-bit) and bytes (9-bit) could be addressed only
> >> via extra indirection words. Where an ordinary pointer fit in 18 bits and
> >> could be in a register, byte or character pointers needed 36 and could
> >> only be in memory.
> >
> >I thought someone else would mention it by now, but another notorious
> >example is the word-addressed DG Nova, which required a separate
> >pointer format to address bytes. C compilers existed for this
> >architecture;
>
>
> I had to program that thing in Interpreted BASIC.... It ran the whole
> company!

Someone who programmed the Singer minis once told me about their
architecture. They had to be programmed in assembler and the assembly
language was so convoluted that they had to use a pre-processor written
in Snobol.

Leon

In article <1149974739.342327.46730@f6g2000cwb.googlegroups.com>, toby
<toby@telegraphics.com.au> writes
>Alex Colvin wrote:
>> >Since there is a thread on "C friendly" architectures, I thought it
>> >might be interested to find out what sort of horrible architectures
>> >compiler writers actually managed to create a C compiler for.
>>
>> There was an early C compiler for the GE 635, which had (36-bit) word
>> addressing. Characters (6-bit) and bytes (9-bit) could be addressed only
>> via extra indirection words. Where an ordinary pointer fit in 18 bits and
>> could be in a register, byte or character pointers needed 36 and could
>> only be in memory.
>
>I thought someone else would mention it by now, but another notorious
>example is the word-addressed DG Nova, which required a separate
>pointer format to address bytes. C compilers existed for this
>architecture; 


I had to program that thing in Interpreted BASIC.... It ran the whole
company!
>

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Paul Keinanen wrote:
> ...
> The Unicode scalar value (USV) range is 0.. 0x10FFFF, thus requiring
> 21 bits, thus, three Unicode characters would nicely fit into a 64 bit
> word with one spare bit ("UTF-64"). Some kind of packed array of char
> mechanism would be required to access individual characters.

Now I'm really getting d=E9j=E0 vu.

>=20
> Paul

Paul Keinanen wrote:
> On 10 Jun 2006 14:25:39 -0700, "toby" <toby@telegraphics.com.au>
> wrote:
> ...
> The Unicode scalar value (USV) range is 0.. 0x10FFFF, thus requiring
> 21 bits, thus, three Unicode characters would nicely fit into a 64 bit
> word with one spare bit ("UTF-64"). Some kind of packed array of char
> mechanism would be required to access individual characters.

Now I'm really getting d=E9j=E0 vu.

>=20
> Paul

On 10 Jun 2006 14:25:39 -0700, "toby" <toby@telegraphics.com.au>
wrote:

>Alex Colvin wrote:
>> >Since there is a thread on "C friendly" architectures, I thought it
>> >might be interested to find out what sort of horrible architectures
>> >compiler writers actually managed to create a C compiler for.
>>
>> There was an early C compiler for the GE 635, which had (36-bit) word
>> addressing. Characters (6-bit) and bytes (9-bit) could be addressed only
>> via extra indirection words. Where an ordinary pointer fit in 18 bits and
>> could be in a register, byte or character pointers needed 36 and could
>> only be in memory.

The same problems occurred with the Univac-11xx series, which used
word addressing with 36 bit words and 6/9 bit characters.

>I thought someone else would mention it by now, but another notorious
>example is the word-addressed DG Nova, which required a separate
>pointer format to address bytes. 

This problem also occurs with any 16/24/32 bit DSP, which do not have
byte addressing.

In many Pascal systems, this problem was solved with the "packed array
of char", which had a limited set of operands compared to "array of
char", in which each character occupied a memory word. 

In future high level systems with 64 bit ALUs, do we really need 8 bit
byte addressing ? The 8 bit byte is insufficient to express all
characters in many major languages of the world.

The Unicode scalar value (USV) range is 0.. 0x10FFFF, thus requiring
21 bits, thus, three Unicode characters would nicely fit into a 64 bit
word with one spare bit ("UTF-64"). Some kind of packed array of char
mechanism would be required to access individual characters.

Paul

Alex Colvin wrote:
> >Since there is a thread on "C friendly" architectures, I thought it
> >might be interested to find out what sort of horrible architectures
> >compiler writers actually managed to create a C compiler for.
>
> There was an early C compiler for the GE 635, which had (36-bit) word
> addressing. Characters (6-bit) and bytes (9-bit) could be addressed only
> via extra indirection words. Where an ordinary pointer fit in 18 bits and
> could be in a register, byte or character pointers needed 36 and could
> only be in memory.

I thought someone else would mention it by now, but another notorious
example is the word-addressed DG Nova, which required a separate
pointer format to address bytes. C compilers existed for this
architecture; Chris Torek and Michael Meissner often mention its
quirks:
http://groups.google.com/group/alt.folklore.computers/msg/b7a12c8764051e8e
http://groups.google.com/groups?as_q=3Dnova+pointer&as_uauthors=3Dchris+tor=
ek

>
> On the other hand, it was otherwise pretty conventional - flat address
> space (unless you were running Multics on a VM-enabled processor),
> call/return through registers or memory stacks, twos complement.
>=20
>=20
> --=20
> 	mac the na=EFf

Le Sat, 03 Jun 2006 10:05:04 +0200, Anton Erasmus a &eacute;crit&nbsp;:

> Hi,
> 
> Since there is a thread on "C friendly" architectures, I thought it
> might be interested to find out what sort of horrible architectures 
> compiler writers actually managed to create a C compiler for.
> (And what portion of the ISO C standard is/was not supported)
> I asked the question (emailed Plauger if I recall correctl) once, on
> why there is no "rotate" operator in C. ALL the architectures I have
> ever work on had a direct assembly instruction for rotating a
> register. The answer was that there were architectures which C
> supports on which a "rotate" instruction made no sense. An example
> was mention of an architecture that had NO integer support at the
> assembly level. Integer operations had to be emulated using floating
> point instructions.
> 
> Regards
>   Anton Erasmus


PIC and 6805, 6808

C Code generated for 68xx and 8051 is usually bloated.

If you design with a PIC you will prefer a C Compiler, CCS does a good
one that masks all the weird stuff and you don't have to worry about
the ridiculous paging system.




-- 
Tired of Microsoft's rebootive multitasking?
then it's time to upgrade to Linux.
http://home.comcast.net/~mcatudal
We are the Cybernetic Entomology Experts