Re: [9fans] Plan9 16bit C compilers

Re: [9fans] Plan9 16bit C compilers

[forsyth]

>>A C implementor might well choose "int" to be 32 bits even
>>on a machine where 64 bits would be more natural, in order
>>to ease importing of code written sloppily on a so-called
>>32-bit platform.

or perhaps just to avoid wasting space on even more zero bits,
especially if there is little or no cost associated with the use of 32
bits instead of 64.

Re: [9fans] Plan9 16bit C compilers

[Thomas Bushnell, BSG]

forsyth@caldo.demon.co.uk writes:

> or perhaps just to avoid wasting space on even more zero bits,
> especially if there is little or no cost associated with the use of 32
> bits instead of 64.

Since memory is so expensive these days...

Re: [9fans] Plan9 16bit C compilers

[Scott Schwartz]

> Since memory is so expensive these days...

Since time is related to space...
Since x86 maxes out at 32bits...
Since linux plants shared libraries in the middle of your address space...
Yes, not wasting memory is very important, still.

Re: [9fans] Plan9 16bit C compilers

[Douglas A. Gwyn]

"Thomas Bushnell, BSG" wrote:
> Since memory is so expensive these days...

In many embedded applications, every bit counts,
more for power consumption reasons than for manufacturing cost.

Re: [9fans] Plan9 16bit C compilers

[Boyd Roberts]

"Douglas A. Gwyn" wrote:
> In many embedded applications, every bit counts,
> more for power consumption reasons than for manufacturing cost.

Very true, but in the case of the Alpha: that thing was always
going to have a heap of memory -- but you already knew that :)

Re: [9fans] Plan9 16bit C compilers

[Thomas Bushnell, BSG]

"Douglas A. Gwyn" <DAGwyn@null.net> writes:

> "Thomas Bushnell, BSG" wrote:
> > Since memory is so expensive these days...
> 
> In many embedded applications, every bit counts,
> more for power consumption reasons than for manufacturing cost.

Right.  But the discussion was about what to do on a 64 bit machine.
I think those processors are not in significant use in embedded
applications.

Re: [9fans] Plan9 16bit C compilers

[George Michaelson]

> "Douglas A. Gwyn" <DAGwyn@null.net> writes:
> 
> > "Thomas Bushnell, BSG" wrote:
> > > Since memory is so expensive these days...
> > 
> > In many embedded applications, every bit counts,
> > more for power consumption reasons than for manufacturing cost.
> 
> Right.  But the discussion was about what to do on a 64 bit machine.
> I think those processors are not in significant use in embedded
> applications.

MIPS sell more CPU's for embedded purposes than core desktop/scientific
computing don't they? I thought it was the #1 chip for lasers and other
devices.

What kind of CPU's do you think will power GPRS video-enabled cellphones?

Is this only the domain of special purpose codecs?

And games consoles are 64bit, and do not have anything like large enough
memory. I know 4mbyte is not as constrained as the 16-bit controller in a
washingmachine, but for once, the rendered video framebuf's probably are a
legit use of what memory there is there. Code can't take it all.

No?

-George

Re: [9fans] Plan9 16bit C compilers

[Thomas Bushnell, BSG]

ggm@apnic.net (George Michaelson) writes:

> MIPS sell more CPU's for embedded purposes than core desktop/scientific
> computing don't they? I thought it was the #1 chip for lasers and other
> devices.

Last I heard a MIPS was a 32 bit processor.  

> And games consoles are 64bit, and do not have anything like large enough
> memory. I know 4mbyte is not as constrained as the 16-bit controller in a
> washingmachine, but for once, the rendered video framebuf's probably are a
> legit use of what memory there is there. Code can't take it all.

I don't know how much memory they have at all.  Do you? 

Re: [9fans] Plan9 16bit C compilers

[George Michaelson]

> I don't know how much memory they have at all.  Do you? 
> 

	Nintendo64 System Description

    64-bit MIPS RISC 93.75MHz CPU (customized R4300i series)

    36Mbit (4.5MB) Rambus DRAM [4MB + parity].
    500MHz system event speed 
	[250MHz clock, data transfers on both clock edges].  
    32bit RGBA frame buffer.

From:
	http://www.futuretech.vuurwerk.nl/sysdesc.html

cheers
	-George

--
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3858 3100  |  Australia
  Fax: +61 7 3858 3199  |  http://www.apnic.net

Re: [9fans] Plan9 16bit C compilers

[anothy]

// Last I heard a MIPS was a 32 bit processor.  

MIPS produces both 32 and 64 bit processors.

it is true that MIPS sells far more chips for embeded systems
than for desktops/servers. shortly after the MIPS-based Nintendo
64 started shipping, MIPS became the most common 64 or 32 bit
embeded chip (finally dislodging one of the 68K series from the
top spot). i'm not sure if it's still #1.
ア

Re: [9fans] Plan9 16bit C compilers

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 201 bytes --]

yes, but perhaps i'd like to put the extra memory to more constructive use if i've
got a lot of it.  perhaps i'd even like to buy less of it anyway so i
can put the money to better use elsewhere.


[-- Attachment #2: Type: message/rfc822, Size: 1880 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] Plan9 16bit C compilers
Date: Wed, 20 Feb 2002 10:08:47 GMT
Message-ID: <87zo24ln69.fsf@becket.becket.net>

forsyth@caldo.demon.co.uk writes:

> or perhaps just to avoid wasting space on even more zero bits,
> especially if there is little or no cost associated with the use of 32
> bits instead of 64.

Since memory is so expensive these days...

Re: [9fans] Plan9 16bit C compilers

[Richard Miller]

The original question from steve.simon@snellwilcox.com was

> Are there any 16bit ports of the plan9 C compiler?

I've ported (more accurately: retargeted) it for a 16-bit CPU which is
embedded in a smartcard.  Because registers are 16 bits and I could
live within a 64KB address space, I chose to make sizeof(int) = 2,
sizeof(int*) = 2, sizeof(long) = 4.  This avoided the need to keep
pointers in pairs of registers, but required some extra rewriting
because the existing compilers have some implicit assumptions
that sizeof(register) = sizeof(long) = sizeof(int*).

There is also one place in the "machine independent" part of the compiler
(/sys/src/cmd/cc/dcl.c:/^contig) which assumes sizeof(long) = sizeof(int*).
Nothing else in cc needed to be touched.

-- Richard

Re: [9fans] Plan9 16bit C compilers

[Scott Schwartz]

Richard Miller writes:
| There is also one place in the "machine independent" part of the compiler
| (/sys/src/cmd/cc/dcl.c:/^contig) which assumes sizeof(long) = sizeof(int*).
| Nothing else in cc needed to be touched.

Send in a patch!  

Re: [9fans] Plan9 16bit C compilers

[Fco.J.Ballesteros]

Well, this time I don't want a `portable' program, since
some of the Plan 9 C extensions are *really* convenient.
It would be great if you could send me your C translator.

Re: [9fans] Plan9 16bit C compilers

[Russ Cox]

> Now that we talk about compilers, anyone used 8c to generate
> binaries on Linux? I saw that emu is compiled using `cc' and not 8c. 
> My actual question is: anyone used Plan 9 C extensions on programs that
> must run on Linux (eg emu)?

I got 8c/8l to generate a Linux 'hello world' program and then stopped.
vc/vl have been used to generate Irix binaries for a while.
I also have a basic C translator, from Plan 9 C to ANSI C.
All of these seem not quite reasonable.  If you want portable
programs, better to write portable code.

Russ

Re: [9fans] Plan9 16bit C compilers

[Russ Cox]

> Or at least I *hope* the Plan9 coders used
> long instead of int when they needed more than 16 bits, something
> that has been standard practice since about 1977.

There's a difference between long and int?!?!?!?

Re: [9fans] Plan9 16bit C compilers

[Boyd Roberts]

Russ Cox wrote:
> There's a difference between long and int?!?!?!?

Look at what Digital did on the alpha:

    int = 32 bits
    long = 64 bits

Duh ...

int was always intended to be the machine's 'word' size [64 bit].

Re: [9fans] Plan9 16bit C compilers

[Douglas A. Gwyn]

Boyd Roberts wrote:
> int was always intended to be the machine's 'word' size [64 bit].

ISAs aren't always so simple these days; orginally a "word"
was a common measure for instruction, non-floating datum,
address, width of data bus, with of memory access, etc., but
now these often don't match each other so one is hard-put to
name a definite "word" size.
A C implementor might well choose "int" to be 32 bits even
on a machine where 64 bits would be more natural, in order
to ease importing of code written sloppily on a so-called
32-bit platform.

Re: [9fans] Plan9 16bit C compilers

[Boyd Roberts]

"Douglas A. Gwyn" wrote:
> A C implementor might well choose "int" to be 32 bits even
> on a machine where 64 bits would be more natural, in order
> to ease importing of code written sloppily on a so-called
> 32-bit platform.

True, but that code is broken and should be fixed.

That was probably the rational behind the choice Digital made
with the Alpha, which I think was completely wrong.  I don't
know who made the decision [CRL?], but I argued against it at
the time.

Porting ULTRIX to it would have been pretty sporty, but they
chose OSF.

Re: [9fans] Plan9 16bit C compilers

[forsyth]

we aim to avoid Plan 9 C extensions (indeed any C extensions at all) when
writing code that's intended to work in hosted mode for Inferno (ie, emu).
// as comments tends to slip through from time to time because so many
compilers accept it, but i sort it out when i notice (at least one of the target
platforms won't accept it).

the problem with using Plan 9 (or Inferno) compilers to generate code
for other architectures is that the object code runtime conventions of
the target machines's native compilers are often unattractive.  for instance,
on the SPARC, the plan 9 suite doesn't use register windows; on the powerpc,
i avoided using any of the ABIs because there are several and they all involve
some mess.  sometimes the Inferno/Plan9 suites can do things the other compilers
don't.  for instance, again on the powerpc, i found it effective to set R0 to
0, given that the hardware makes it less than general purpose 1/3 of the time,
and  i saved a few percent in code size as a result.  i also avoided having
all that `module linkage' crud in procedure calls.

as another example, the Plan 9/Inferno suite assumes caller-saves for all
volatile registers on all architectures.  this makes it hard -- not impossible,
but requiring care -- to interact with native compiled code in libraries
in some cases.

on the 386, though, where there are precious few sensible registers
and fewer options for interesting use of the instructions, there probably is
enough compatibility between the object code models that it would be feasible
to generate code for Linux and others.  shared libraries
are a potential complication, i suppose (hello, geoff and boyd).
i thought someone had got the Plan 9 or Inferno compilers cross-compiling
for Linux, though.

Re: [9fans] Plan9 16bit C compilers

[forsyth]

>>will run slower.)  Or at least I *hope* the Plan9 coders used
>>long instead of int when they needed more than 16 bits, something
>>that has been standard practice since about 1977.

it started out that way in Plan 9, but my impression is that people
don't bother as much any more.  a few things can change in 25 years.

i thought steve simon was asking about using a port of the C compiler as
a cross-compiler.    it might well be feasible.   the compiler distinguishes
short, int and long (and others such as vlong) internally, allowing them
different sizes.  (at one time, it sometimes blurred int and long when type checking
but that was changed some time ago.)

Re: [9fans] Plan9 16bit C compilers

[Boyd Roberts]

Depends on the problem, but from what I know about the assembler
output it's the loader that does the instruction generation.

The PDP-11 was a 16 bit machine, but it did have 32 bit longs,
and software FP support if the machine didn't have an FPU.

Re: [9fans] Plan9 16bit C compilers

[Fco.J.Ballesteros]

Now that we talk about compilers, anyone used 8c to generate
binaries on Linux? I saw that emu is compiled using `cc' and not 8c. 
My actual question is: anyone used Plan 9 C extensions on programs that
must run on Linux (eg emu)?

thanks

Re: [9fans] Plan9 16bit C compilers

[nigel]

[-- Attachment #1: Type: text/plain, Size: 145 bytes --]

Not that there is an 80c165 compiler for Inferno or Plan9, but I
have to say that Inferno would be a much better prospect on
that hardware.


[-- Attachment #2: Type: message/rfc822, Size: 2353 bytes --]

From: steve.simon@snellwilcox.com
To: 9fans@cse.psu.edu
Subject: [9fans] Plan9 16bit C compilers
Date: Thu, 14 Feb 2002 16:15:02 +0000
Message-ID: <1463098921@snellwilcox.com>

Hi,

Are there any 16bit ports of the plan9 C compiler?

We do embedded software using the Siemens / Infineon 80C165
CPU (Big brother of the 8051) and would love to use Plan9 as the main
development platform.

I know the plan9 compiler has been designed to be portable but has
anyone tried to port it to a 16 bit CPU?
Does anyone have opinions on how difficult it might be?

I guess I am just dreaming... but maybe one day, when I have time...

-Steve


----------------------------------------------------------------------
The contents of this communication are confidential to the normal user of
the email address to which it was sent.  If you have received this email
in error, any use, dissemination, forwarding, printing or copying of this
email is strictly prohibited.  If this is the case, please notify the
sender and delete this message.
---------------------------------------------------------------------- 

[9fans] Plan9 16bit C compilers

[steve.simon]

Hi,

Are there any 16bit ports of the plan9 C compiler?

We do embedded software using the Siemens / Infineon 80C165
CPU (Big brother of the 8051) and would love to use Plan9 as the main
development platform.

I know the plan9 compiler has been designed to be portable but has
anyone tried to port it to a 16 bit CPU?
Does anyone have opinions on how difficult it might be?

I guess I am just dreaming... but maybe one day, when I have time...

-Steve


----------------------------------------------------------------------
The contents of this communication are confidential to the normal user of
the email address to which it was sent.  If you have received this email
in error, any use, dissemination, forwarding, printing or copying of this
email is strictly prohibited.  If this is the case, please notify the
sender and delete this message.
---------------------------------------------------------------------- 

Re: [9fans] Plan9 16bit C compilers

[Douglas A. Gwyn]

steve.simon@snellwilcox.com wrote:
> anyone tried to port it to a 16 bit CPU?

What is a "16-bit CPU"?
If you mean that a single address space is limited to 2^16 bytes,
then that seems to be too small for Plan9.
If you mean that the fast registers are 16 bits wide,
then the porting job shouldn't be any worse than for 32-bit wide
registers, all other architectural details being equal.  (But it
will run slower.)  Or at least I *hope* the Plan9 coders used
long instead of int when they needed more than 16 bits, something
that has been standard practice since about 1977.