new C compiler (easy C)
Peter De Rijk
about it: How good is the compiler. How is its environment, etc.
How does it compare to Desktop C.
Thanks in advance for all info,
Peter
Ian Palmer
: I have read that a new C compiler is out. Could somebody tell something more
: about it: How good is the compiler. How is its environment, etc.
: How does it compare to Desktop C.
I assume you're talking about the Risc Developements' one. Is it out
yet, or (like everything at the moment) going to be released at 'the
show'. I doubt many people will have had a go with it yet even if it
is out. Although the (or one of the) author is on the net somewhere
(me thinks), but then he'd be biased :-)
It would certainly be interesting to see how it faired, although I
can't imagine anyone buying it AND Acorn's Desktop C in order to do a
side by side comparison (you'd have to leave that upto magazines, and
they'd probably make a complete hash of any side by side test
(for testing how well it optimises they'd probably just compile the
dhrystone (I'm sure there's an 'h' in there somewhere) test with each
and be done with it, forgetting the tendancy for compiler writers to
create special optimisations for standard tests (not forgetting CPU
manufacturers producing special instructions for standard benchmark
tests, but that's irrelevant here)).
It's advantage over Desktop C is it's built in (or is it just supplied
with it, probably) assembler (Personally I think Acorn should have
bundled their assembler with Desktop C, who wants to pay for DDE twice
(most would say it wasn't worth it the first time round ;-) )
As I understand it it (the RD one) doesn't have any desktop support,
(library wise) so you'd have to rely on something like DeskLib (which
is patchy in some areas).
It would also be interesting to see just how ANSI compliant it is (it
claims (I think) to be fully, but then don't they all). Considering
the fact that someone posted here recently that the Acorn (NorCroft)
compiler was one of two that where shown to be fully ANSI compliant in
tests (the other being Sun's ANSI compiler) (Yes NO PC compiler
passed, dance in the streets, clap your hands, etc.), it's got a tough
job matching that aspect of the Acorn compiler. (This reminds me of
the C compiler Beebug (as it was then) produced for the BBC Micro. It
took me 10 minutes to find a program that it failed to compile
correctly (well I say 10 minutes, that's how long it took to find that
there was a problem, it took 3 weeks to work out that it wasn't a bug
in my code but rather the total inability for the compiler to handle
two dimentional arrays of pointers).
Ian
---
"You pay for it before you eat it? e-mail: i...@doc.ic.ac.uk
What happens if it's dreadful?" tel: +44 71 589 5111 (x7525)
"That's why." fax: +44 71 581 8024
(Terry Pratchett, Moving Pictures)
___ _ Ian Palmer, Department of Computing,
/ _ _ /_) _ / _ _ _ _ Imperial College, 180 Queen's Gate,
____/__(_|_| )__/ __(_|_(_| ) )_|/_) _______London SW7 2BZ. England.____________
Dave Allison
>Peter De Rijk (der...@reks.uia.ac.be) wrote:
>: I have read that a new C compiler is out. Could somebody tell something more
>: about it: How good is the compiler. How is its environment, etc.
>: How does it compare to Desktop C.
>
>I assume you're talking about the Risc Developements' one. Is it out
>yet, or (like everything at the moment) going to be released at 'the
>show'. I doubt many people will have had a go with it yet even if it
>is out. Although the (or one of the) author is on the net somewhere
>(me thinks), but then he'd be biased :-)
>
Hello, I am here. You're probably right, I am biased. I think the compiler
is pretty good. Since I wrote it on my own (in assembler, in my spare time)
it doesn't have the support as the acorn model, but it is a fully
functional C compiler. Dare I say it, but Acorn haven't exactly been
helpful (I suppose I can't blame them). The package is aimed and the
lower end of the market and costs less then 50 quid. For your money you
get an ANSI compiler, ARM assembler, fast linker and a librarian. It will
run on a 1 Meg machine (it was developed on a 1MB A310).
For those who wish to know, I'll give some information about it.
The package consists of a module and a WIMP front end. The module contains
the compiler, assembler linker and librarian. The desktop front end is
easy to use (hence the name) and sends commands to the module. It gets
messages back for errors etc. There is a make facility (including the
ability to create makefiles for you). It works with throwback. You compile
a file by dragging it to the front end and clicking on Compile. Click
on Link to link all the files.
[ deletions ]
>
>It's advantage over Desktop C is it's built in (or is it just supplied
>with it, probably) assembler...
Yes, I am quite proud of the assembler bit. It was not very difficult to do
(I wrote it in a weekend). It is actually part of the compiler and is
fully integrated. To use it you simply enclose your assembly language
in #pragma asm ... #pragma endasm pairs. It understands all the usual
register names, SWI names etc and it is fully compatible with the
preprocessor (so you can use the normal C macro constructs).
>
>As I understand it it (the RD one) doesn't have any desktop support,
>(library wise) so you'd have to rely on something like DeskLib (which
>is patchy in some areas).
>
It works with desklib (and also RISCOS_Lib if you have it).
>It would also be interesting to see just how ANSI compliant it is (it
>claims (I think) to be fully, but then don't they all).
I wrote it to be compliant with ANSI C. It passed the Plum Hall deviance
tests but it costs too much to run it through ANSI test suites. Certainly,
I have been using it for development of software using ANSI constructs and
it works fine. It might not pass some tests for the obscure features
of the standard, but who cares anyway.
(This reminds me of
>the C compiler Beebug (as it was then) produced for the BBC Micro.
Sorry, that was me too. It was a very hard thing to squeeze a full compiler
and linker into 32K on a 6502. I know it wasn't perfect, but when you have
120 bytes to spare, there is not a lot you can do when a major bug is found.
>
The front end for the Easy C system was written using my compiler and I found
no bugs in it. I am also working on other related products using the compiler,
but I dont know if I can say what.
If anyone wants more info, give me a shout (email shout that is).
Dave
---
Dave Allison, BT Belfast Engineering Centre
dall...@bfsec.bt.co.uk +44 232 894297
*
==_-- ....... . .. . ... . .. ***
*
All view expressed as mine and as such are Copyright 1993 me
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Joe Walker
I can tell you about the old Beebug C vs Acorn C.
The position was simple:
Acorn C produces ~2x faster code
is more bug free
has better dev environ
libraries
documentation
&c.
Beebug C was a lot cheaper (~70UKP vs ~200UKP)
Easy C is I beleive Beebug C without the Acorn libs.
with a better dev environ.
Some may regard lack of Acorn lib to be a bonus ;-)
IMHO it goes like this:
If want to produce merchantable code get Acorn C.
If you cant afford this but can get access to Acorn C (e.g. at Uni &c)
then buy Easy C and then compile the final version on Acorn C.
Otherwise get Easy C
BTW if anyone wants to buy an almost unused Beebug C I could sell you a
2nd hand copy for say 50UKP ono. Mail me and haggle.
Joe.
--------------------------------------------------------
Systems Engineer Tel: +44-(0)793-545346
ESS Group Fax: +44-(0)793-420915
Motorola ECID, 16 Euroway, Blagrove, Swindon, UK
E-Mail, <walk...@zeus.swindon.rtsg.mot.com>
--------------------------------------------------------
Graham Barr
>In article <1993Oct1.0...@reks.uia.ac.be>, der...@reks.uia.ac.be (Peter De Rijk) writes:
>> I have read that a new C compiler is out. Could somebody tell something more
>> about it: How good is the compiler. How is its environment, etc.
>> How does it compare to Desktop C.
>>
>> Thanks in advance for all info,
>>
>> Peter
>I can tell you about the old Beebug C vs Acorn C.
>The position was simple:
> Acorn C produces ~2x faster code
> is more bug free
> has better dev environ
> libraries
> documentation
> &c.
> Beebug C was a lot cheaper (~70UKP vs ~200UKP)
>
>Easy C is I beleive Beebug C without the Acorn libs.
> with a better dev environ.
Does this mean that an int and a short are both 32 bits, as in
BeeBug C or have they fixed it to be 16 bits now.
>Some may regard lack of Acorn lib to be a bonus ;-)
>
>IMHO it goes like this:
>If want to produce merchantable code get Acorn C.
> If you cant afford this but can get access to Acorn C (e.g. at Uni &c)
> then buy Easy C and then compile the final version on Acorn C.
>Otherwise get Easy C
>
>BTW if anyone wants to buy an almost unused Beebug C I could sell you a
>2nd hand copy for say 50UKP ono. Mail me and haggle.
I also have a almost unused copy of BeeBug C I could sell for 50UKP.
Does this say anything about BeeBug C ????
Graham.
_____________________________________________________________________________
Graham Barr
MOS Design Email: a90...@server1.tiuk.ti.com
Texas Instruments Ltd Phone: (work) (0234) 223419
BEDFORD
ENGLAND
You don't get anywhere without Risc's !!!
_____________________________________________________________________________
Dave Allison
>Does this mean that an int and a short are both 32 bits, as in
>BeeBug C or have they fixed it to be 16 bits now.
>
It doesn't say ANYWHERE that shorts have to be 16 bits. It pisses me
off that just because one compiler uses 16 bits seems to constitute a standard!
Why doesn't someone complain that ints are 32 bits because they are 16 on
a PC.
A short being 16 bits on the ARM requires 2 registers, 2 LDRB instructions and
ORR instruction and a couple of MOVs for sign extension. Is it really worth
it for the sake of matching what Acorn do. Anyway, it is very bad practice
to write your software which relies on ints and shorts having certain sizes.
If you want 16 bit shorts, use bitfields.
>Does this say anything about BeeBug C ????
>
Yes, it's cheaper than Acorns, and perhaps not as good. But then again, Acorn
did spent 250,000 UKP in development!
Graham Barr
>>Does this mean that an int and a short are both 32 bits, as in
>>BeeBug C or have they fixed it to be 16 bits now.
>>
>
>It doesn't say ANYWHERE that shorts have to be 16 bits. It pisses me
>off that just because one compiler uses 16 bits seems to constitute a standard!
>Why doesn't someone complain that ints are 32 bits because they are 16 on
>a PC.
I am not saying that shorts have to be 16 bits. Anyway ANSI states that an
int should be of a size most native to the processor. a short must be no
larger than an int, a long must be no shorter than an int and
a char must be no larger than a short.
What would you say if a char,short,int and a long were all held in 32bits?
>A short being 16 bits on the ARM requires 2 registers, 2 LDRB instructions and
>ORR instruction and a couple of MOVs for sign extension. Is it really worth
>it for the sake of matching what Acorn do. Anyway, it is very bad practice
>to write your software which relies on ints and shorts having certain sizes.
>If you want 16 bit shorts, use bitfields.
Maybe but the idea of a short is that the programmer has decided that
a hit in run time is acceptable for a smaller amount of storage space
>
>>Does this say anything about BeeBug C ????
>>
>
>Yes, it's cheaper than Acorns, and perhaps not as good. But then again, Acorn
>did spent 250,000 UKP in development!
>
_____________________________________________________________________________
Richard Earnshaw
|>
|> It doesn't say ANYWHERE that shorts have to be 16 bits. It pisses me
|> off that just because one compiler uses 16 bits seems to constitute a standard!
|> Why doesn't someone complain that ints are 32 bits because they are 16 on
|> a PC.
|>
using the same size conventions for each type; you can then link modules compiled
with one compiler with modules compiled with another (eg libraries).
|> A short being 16 bits on the ARM requires 2 registers, 2 LDRB instructions and
|> ORR instruction and a couple of MOVs for sign extension. Is it really worth
|> it for the sake of matching what Acorn do. Anyway, it is very bad practice
|> to write your software which relies on ints and shorts having certain sizes.
|> If you want 16 bit shorts, use bitfields.
|>
No, a 16-bit load on the arm requires 1 register, 1 LDR instruction (the rotate
to the correct position is implicit in the address given -- read the data sheet),
and two shifts (to zero- or sign-extend the result). Storing a 16-bit number
does require two STRB's, a shift (and a scratch register if you need to keep the
result).
|> Dave
Richard.
Chris Dollin
A short being 16 bits on the ARM requires 2 registers, 2 LDRB instructions
and ORR instruction and a couple of MOVs for sign extension. Is it really
worth it for the sake of matching what Acorn do.
Isn't it possible to do rather better if your shorts are aligned (as they will
be in most, ie compiler-generated, circumstances)? Especially when they
are at known locations. Eg
void example(void) { short time; short path; ... path ... }
Here ``path'' can be accessed with one LDW and two shifts; the latter may
be combined with the following operation (eg, in ... path + 1 ... the
shift and add can be done together). Similar code can be generated when
the short is part of a data structure.
Hmm, the compiler might be able to do it with one shift if the short is at the
high-order end of the loaded word; presumably about 1/2 the time ...
The most awkward case (I think) is when the short is accessed via a
pointer. This is when the nasty code above might be needed. But, two points:
(a) If the short is aligned (on at least a two-byte boundary), you could
exploit the shifting property of LDW when handed a non-word-aligned address.
[This was documented in one of the ARM textbooks. Is it still valid?] Of
course, you still have to work for stores.
(b) Won't the following code do? Assume that r1 contains the pointer-to-short
and r2 is to contain the extracted value. I apologise for the unorthodox
layout: I never did like the assembler notation.
bic r2, r1, #3 pick off the short bits
ldw r2, [r2] get the whole word
tst r1, #2 was it an odd half-word?
movne r2, r2 shl 16 if so, shift it up to the left
mov r2, r2 asr 16 shift down, sign extending
I guess it's not much better than Dave's use of LDRB+ORR+MOV; it still needs
two registers (although you'd always need at least one anyway, and often
you'd want to load into a separate register from the pointer. Did Dave mean
two *extra* registers?), but there's less access to store.
Update is left as an exercise for the reader ...
--
Regards, | "You're better off not dreaming of the things to come;
Kers. | Dreams are always ending far too soon." - Caravan.
Dave Allison
>No, a 16-bit load on the arm requires 1 register, 1 LDR instruction (the rotate
>to the correct position is implicit in the address given -- read the data sheet),
>and two shifts (to zero- or sign-extend the result). Storing a 16-bit number
>does require two STRB's, a shift (and a scratch register if you need to keep the
>result).
>
I stand (or sit) corrected. Perhaps I will implement shorts as 16 bits if there
is a demand. You can still do it using bitfields though.
Having had to port software written on a SPARC to Microsoft C, I am a great
believer in always using one size of integer (and a char of course). In Microsoft
C, if you pass an int to a function which expects a long, the program crashes
sometime in the future because the stack is screwed up. We dont have that problem
on the Archie because of the callee saving standard, which I think is excellent.
This wont work in Microsoft C:
extern printf (char*,...) ;
long fred ;
printf ("%d\n",fred) ;
No problem if longs and ints are the same size though. What a pain in the butt.
Richard Earnshaw
|> <CEH2y...@bfsec.bt.co.uk> dall...@bfsec.bt.co.uk (Dave Allison) writes:
|>
|> A short being 16 bits on the ARM requires 2 registers, 2 LDRB instructions
|> and ORR instruction and a couple of MOVs for sign extension. Is it really
|> worth it for the sake of matching what Acorn do.
|>
|> exploit the shifting property of LDW when handed a non-word-aligned address.
|> [This was documented in one of the ARM textbooks. Is it still valid?] Of
Yes it is.
|> course, you still have to work for stores.
|>
|> (b) Won't the following code do? Assume that r1 contains the pointer-to-short
|> and r2 is to contain the extracted value. I apologise for the unorthodox
|> layout: I never did like the assembler notation.
|>
|> bic r2, r1, #3 pick off the short bits
|> ldw r2, [r2] get the whole word
|> tst r1, #2 was it an odd half-word?
|> movne r2, r2 shl 16 if so, shift it up to the left
|> mov r2, r2 asr 16 shift down, sign extending
|>
|> I guess it's not much better than Dave's use of LDRB+ORR+MOV; it still needs
|> two registers (although you'd always need at least one anyway, and often
|> you'd want to load into a separate register from the pointer. Did Dave mean
|> two *extra* registers?), but there's less access to store.
|>
I think it is worse:
It takes more instructions for starters, it still requires two registers, it
clobbers the condition codes....
With Dave's code (which is shorter), the second byte read will be from cache
(assuming you have one), so will be no slower that any other data operation.
But the optimal sequence is:
ldr r1, [r0] Offset automatically handled.
mov r1, r1, asl #16
mov[s] r1, r1, (asr/lsr) #16 (sign or zero-extend, and optionaly
set flags)
What is even more important is that this allows additional memory addressing
modes to be used, like pre/post increment and even fancy shift-add
expressions (eg: ldr r1, [r0, r2, asl #2]! )
These just cannot be done by your version without making the instruction
sequence longer still.
There is also the issue of what you are then going to do with the number you
have just loaded. If you are going to do a logical operation on it, or
simply store it again somewhere else, then there is no need to do the shift
operations (at least not at that point).
|> Update is left as an exercise for the reader ...
The absence of a true 16-bit store is a real pain :-(
|> --
|>
|> Regards, | "You're better off not dreaming of the things to come;
|> Kers. | Dreams are always ending far too soon." - Caravan.
Richard
D.Pead
>>
>
>It doesn't say ANYWHERE that shorts have to be 16 bits. It pisses me
>off that just because one compiler uses 16 bits seems to constitute a standard!
to have a 16-bit type available.
>Why doesn't someone complain that ints are 32 bits because they are 16 on
>a PC.
>
Because int is MEANT to be the natural word size of the machine, that's
why.
>A short being 16 bits on the ARM requires 2 registers, 2 LDRB instructions and
>ORR instruction and a couple of MOVs for sign extension. Is it really worth
>it for the sake of matching what Acorn do. Anyway, it is very bad practice
>to write your software which relies on ints and shorts having certain sizes.
Sorry, but:
#ifdef MACHINE1
typedef int sixteenbit;
#endif
#ifdef MACHINE2
typedef short sixteenbit;
#endif
... good practice, but *?!## impossible if the compiler doesn't define
a 16 bit type.
>If you want 16 bit shorts, use bitfields.
>
er, if you are suggesting:
typedef struct {
unsigned s: 16;
} myshort;
Then there are 2 small flies in the ointment.
1. Myshort is a composite type and not an arithmetic type, so
it's not a direct substitute for a 16-bit short.
2. A lot of 32-bit compilers pad structures out to 32-bit
boudaries. On Acorn C, for example, sizeof(myshort)=4.
not an enormous amount of use if you're trying to
save space or read DOS binary files.
Torben AEgidius Mogensen
>No, a 16-bit load on the arm requires 1 register, 1 LDR instruction (the rotate
>to the correct position is implicit in the address given -- read the data sheet),
>and two shifts (to zero- or sign-extend the result). Storing a 16-bit number
>does require two STRB's, a shift (and a scratch register if you need to keep the
>result).
I have done even better in some programs. The 16-bit integers are
organized so the actual address of an integer is (A xor 2) where A is
the "logical" address of the number. A To load an integer at "logical"
address A to register R, you use the sequence
LDR R,A
ASR R, #16 (or LSR)
The alignment of the load will store the number in the 16 most
significant bits, so a single shift is enough to sign extend (or zero
extend) the number. Storing still requires two STRBs.
This stratgey will, however, play hell with programs that assume
anything about the layout of arrays etc. But I believe the ANSI
socalled "standard" is liberal enough to say this is undefined anyway.
Torben Mogensen (tor...@diku.dk)
Richard Earnshaw
Yes, but in the general case A must be a single register, or a register
plus a constant when the register is known to contain a multiple of 4.
With the second case you can indeed do the sequence in two instructions,
but in all other cases you need an EOR instruction as well, and you cannot
use this method either with the extended addressing modes.
Within a compiler, spotting such an optimization would be *very* hard
(though, probably, not impossible).
Richard.
Terry Moffitt
I get the impression that some people don't like the sound of Easy C.
Why knock it before you see it or use it ?
Personally, I think it is pretty damn good. I have used it over the last
couple of months and have had no problems with it. If you use it from the
desktop, the compilation/linking process couldn't be simpler. Everything
about the front end is very user-friendly. This, along with the ability to
use the system from the CLI, enables both beginners and 'old hands' to use
it 'with comfort'.
The C icon sits on the icon bar and works in the standard way. Then all you
have to do is to drag your source files in and click on compile. It'll even
automatically link for you (as well as having the ability to generate a make
file). A good system I reckon. Ok, so there was the odd bug (feature) which
appeared once in a blue moon, but, after all, I was helping to test it for
Dave Allison (the author).
I haven't used Acorn C, so I can't compare it, the reason being that I'm not
crazy enough to fork out that amount of money when a cheaper one exists which
does as good a job and is professional in appearance and operation.
Dave has already posted details of Easy C, so I don't need to repeat anything
he has said. The only thing I would disagree on is that he reckons that Easy C
is not capable of developing serious large applications. His only qualm was
that code generated by Acorn C is slightly faster than his. If the application
is that dependant on speed of execution then use assembler (which is very well
catered for in Easy C).
Overall, I like using it and will continue to do so, even for 'serious'
applications.
And no, I'm not getting a cut for recommending it! Like my sig. says, it's
my opinion....
----------------------------------------------------------------------------
Terry Moffitt - BT Belfast Engineering Centre
tmof...@bfsec.bt.co.uk +44 232 894436
All opinions expressed are my own.
----------------------------------------------------------------------------
j...@waikato.ac.nz
shorts is all very interesting, BUT what I really want to know is whether your
documentation is any good. If your documentation is not up to a decent
standard (ie.. Macintosh or PC equivalent, NOT Acorn) then I would consider
buying your compiler, but otherwise, I don't give a sh*t.
Writing a compiler is all very well and good, but if you can not explain it
then it's really very pointless.
Jamie.
P.S. And please everybody, do babble on about how there are good C manuals
around and such like. Mac and PC are doing better than Acorn - FACT. Mac and
PC docs are light years better than anything I have seen from Acorn (exclude
Impression manual which actually seems to be genuinely good). Take a hint...
Chris Dollin
Storing a 16-bit number does require two STRB's, a shift (and a
scratch register if you need to keep the result).
Can't you avoid the scratch register by using a rotate rather than a shift?
Jim Noble
>I get the impression that some people don't like the sound of Easy C.
>Why knock it before you see it or use it ?
I think the only people knocking it are those who have spent a small
fortune on !DesktopC :-)
Jim
--
Jim Noble
Dave Allison
>All this stuff about comparing compilers and specifications for representing
>shorts is all very interesting, BUT what I really want to know is whether your
>documentation is any good. If your documentation is not up to a decent
>standard (ie.. Macintosh or PC equivalent, NOT Acorn) then I would consider
>buying your compiler, but otherwise, I don't give a sh*t.
>
>Writing a compiler is all very well and good, but if you can not explain it
>then it's really very pointless.
Interesting point of view. So it doesn't matter what the software is like
if you have good documentation? This must be the premise that Microsoft use!
I agree that documentation is sometimes skimped if time gets short, and that
this is not good. But surely it's the quality fo the software that matters.
Documentation can be done at a later stage by another person, but the software
can't.
D.Pead
>standard (ie.. Macintosh or PC equivalent, NOT Acorn) then I would consider
>buying your compiler, but otherwise, I don't give a sh*t.
>
is poor (but then, so is RISC-OS lib itself!) - I've got no quarrel
with the compiler documentation. I suspect that, if Acorn had just
thrown in some straight SWI veneers (SWIs being good enough for all
those BASIC and assembler programmers out there), then their compiler
would have come in for less stick.
>Writing a compiler is all very well and good, but if you can not explain it
>then it's really very pointless.
>
> Jamie.
>
>P.S. And please everybody, do babble on about how there are good C manuals
>around and such like.
Your wish... there are good C manuals around and such like... it's silly
for compiler writers to waste time and money re-inventing the wheel. I
certainly don't want the waste of a "How to program in C" book bundled
with a new compiler. OK - release 2 of Acorn C (back in Arthurian
times) went a bit far when it suggested you read the ANSI standard, but
it's better to let people decide if they want a reassuringly thick
"C for Duffers" tome or would prefer K&R and strong coffee.
>Mac and PC are doing better than Acorn - FACT. Mac and
>PC docs are light years better than anything I have seen from Acorn (exclude
>Impression manual which actually seems to be genuinely good). Take a hint...
Strangely, the Impression manual is NOT what I would hold up as a good
manual - have you ever tried to FIND anything in it, or do you just
count the pages and pictures?
As for "wonderful" C documentation, all I know of is MS C V6 which had
ABSOLUTELY TERRIBLE documentation (information scattered illogically
between the reference manual, the other book and the on-line docs)
and THINK C (which looks OK, but doesn't exactly blow your socks off
and still needs "Inside Mac" - at least as expensive as the Acorn PRM).
cst...@csv.warwick.ac.uk
rs...@unicorn.nott.ac.uk (D.Pead) writes:
>In article <1993Oct8.0...@waikato.ac.nz> j...@waikato.ac.nz writes:
>>standard (ie.. Macintosh or PC equivalent, NOT Acorn) then I would consider
>>buying your compiler, but otherwise, I don't give a sh*t.
>>
>Now let's get specific here - the Acorn documentation for RISC-OS lib
>is poor (but then, so is RISC-OS lib itself!) - I've got no quarrel
>with the compiler documentation. I suspect that, if Acorn had just
>thrown in some straight SWI veneers (SWIs being good enough for all
>those BASIC and assembler programmers out there), then their compiler
>would have come in for less stick.
I'd disagree -- RISC_OSlib is a praiseworthy attempt at an event-driven
interface to the RISC OS Window Manager, with object-oriented overtones.
(It's a shame that subclassing windows came in release 4, but then...) It's
needed some patching up (about 15000 lines worth last time I looked at
my source) but the ideas are sound. I think that any system that makes
it easier to write a multidocument editor than a single document one
deserves a small measure of credit to go to the designers. The docs
are adequate, although I'd have preferred the printed docs not
to be just a rehash of the header file comments, and maybe some hypertext
docs would be nice. (Compared to the docs supplied with the now venerable
Beebug C Development System, Acorn's description is truly marvellous,
although that ain't difficult.)
>>Writing a compiler is all very well and good, but if you can not explain it
>>then it's really very pointless.
>>
>> Jamie.
>>
>>P.S. And please everybody, do babble on about how there are good C manuals
>>around and such like.
>
>Your wish... there are good C manuals around and such like... it's silly
>for compiler writers to waste time and money re-inventing the wheel. I
>certainly don't want the waste of a "How to program in C" book bundled
>with a new compiler. OK - release 2 of Acorn C (back in Arthurian
>times) went a bit far when it suggested you read the ANSI standard, but
>it's better to let people decide if they want a reassuringly thick
>"C for Duffers" tome or would prefer K&R and strong coffee.
I quite agree -- I've got enough manuals on C from various compilers (from
Micro$oft QuickC versions 1 and 2 through Borland Turbo C++ to IBM C Set/2)
all describing different variants. I'd rather just have a standard work on
`C' and a *short* description of the differences in each compiler, which
fills in the bits which are left up to the implementation (like structure
and bitfield layouts, and whether rename works on open files). Oh. That's
what Acorn gave me.
>>Mac and PC are doing better than Acorn - FACT. Mac and
>>PC docs are light years better than anything I have seen from Acorn (exclude
>>Impression manual which actually seems to be genuinely good). Take a hint...
>
>Strangely, the Impression manual is NOT what I would hold up as a good
>manual - have you ever tried to FIND anything in it, or do you just
>count the pages and pictures?
Impression's manual isn't what I'd call awful, but the index ain't
marvellous. Then again, Impression doesn't do what I'd call `good indexes'
anyway. It's good at showing a reader how to use the package, but for
later reference, it is a bit of a pig.
[Rest zapped]
---
Straylight
Richard Earnshaw
> Why knock it before you see it or use it ?
If you follow the discussion through from the start, you will note that it
started when Dave commented that he had implemented 'short's as 32 bits on the
grounds that loading a 16-bit number was too slow. I simply pointed out that
there was a far more simple way of loading a 16-bit number, and that I felt
that maintaining compatability with other compilers was an important
consideration that ought to be made. Take for an example a device driver,
which is written in C and has the following struct defined over the hardware
registers.
struct foo
{
int dev_id;
short inport;
short outport;
}
Then Acorn's C compiler will compile this to be of size 8 bytes, and Easy C
will compile it to be of size 12 bytes. Clearly the same code, compiled on
the same machine, but with the different compilers will fail to work for one
of them.
I do not believe in "Knocking" things I haven't seen.
Mike.Ellis
: If you follow the discussion through from the start, you will note that it
: started when Dave commented that he had implemented 'short's as 32 bits on the
: grounds that loading a 16-bit number was too slow. I simply pointed out that
: there was a far more simple way of loading a 16-bit number, and that I felt
: that maintaining compatability with other compilers was an important
: consideration that ought to be made. Take for an example a device driver,
: which is written in C and has the following struct defined over the hardware
: registers.
: struct foo
: {
: int dev_id;
: short inport;
: short outport;
: }
: Then Acorn's C compiler will compile this to be of size 8 bytes, and Easy C
: will compile it to be of size 12 bytes. Clearly the same code, compiled on
: the same machine, but with the different compilers will fail to work for one
: of them.
The important thing is that both compilers are producing correct code from the
source given to them. The fact that the author of the source wrote something
which makes invalid assumptions about the compiler is not the fault of the
compiler writer.
On a different note, can people who know me please note my new email
address - I used to be "m...@ukc.ac.uk" but I'm not any more!
Cheers,
--
Mike Ellis, mi...@dd.eng.bbc.co.uk
BBC (Research and Development Department), Avenue House, Chiswick, London, UK
-- Any opinions expressed are my own and in no way reflect those of the BBC --
Neil Hoggarth
Graham Barr <a90...@server1.tiuk.ti.com> wrote:
>
> I am not saying that shorts have to be 16 bits. Anyway ANSI states that an
> int should be of a size most native to the processor. a short must be no
> larger than an int, a long must be no shorter than an int and
> a char must be no larger than a short.
>
> What would you say if a char,short,int and a long were all held in 32bits?
>
Well it would be allowed according to the ANSI rules. The Motorola port
of GNU C for the 56000 DSP chip has
sizeof(char) == sizeof(short) == sizeof(int) == 24 bits.
and doesn't have problems with well written portable code.
Regards,
-----------------------------------------------------------------
Neil Hoggarth, e-mail : ne...@ntlrd.demon.co.uk
Electronic Engineer, PGP 2.3a public key available
Advanced Products Division, NTL. MIME is spoken here
-----------------------------------------------------------------
A.J. Bolt
has been duplicated enough now.
I personally would not just buy a product because the manuals supplied with it
weighed twice as much as those of the competition. I have Borland Turbo C++
professional (yes - for the Pee Cee!), which comes with an assembler, profiler
and debugger, as well as loads of useful tools, and about 10 manuals, with
information liberally scattered throughout them.
The best documentation from Microsoft that I have seen was the quick peek I got at
_THE_ NT manual. Yes, just one manual for a complete OS, windowing thingy, filing
system, all-singing, all-dancing, package. It seemed fairly complete, although of
course, there was the online documentation to supplement it. BTW, I never got to
see NT running.
The point is, with documentation, quantity is not important. Organisation and
indexing are.
Thank you for listening.
Andrew
Bob Voisey
>Maybe but the idea of a short is that the programmer has decided that
>a hit in run time is acceptable for a smaller amount of storage space
Also, when porting, it is useful to have a representation which is as close
as possible to that used in the unix/pc world. Lots of programs (rightly or
wrongly) load data files and cast pointers to structures - if the
representation of a structure is different on your compiler you have to
completely rebuild the data files. That might be bad programming practice,
but cursing the original author whilst writing a complex file converter
gives little relief.
Actually the Acorn compiler is just as annoying in that respect because it
insists on aligning structure elements all over the place. It took me hours
to work out why some code written for Microsoft C (spit) wasn't working ;-)
Cheers
Bob
--
Go away, else I shall taunt you a second time.
b...@cryton.demon.co.uk vox+44(749)670058 fax+44(749)670809 dat+44(749)670030
Bob Voisey
>Well it would be allowed according to the ANSI rules. The Motorola port
>of GNU C for the 56000 DSP chip has
>sizeof(char) == sizeof(short) == sizeof(int) == 24 bits.
I think this is a slightly special case.. the 56000 is a 24 bit processor
for which most programs are going to be extremely hardware-aware. Code
which makes a big thing of abstract data handling is unlikely to be
ported to this platform..
Bob
PS. Our 56001 podule will be released at Acorn World!
Bob Voisey
But that point is valid.. you don't expect a C tutorial from a C manual.
You expect an in-depth explanation of the compiler and it's libraries (which,
I admit, is not too hot with Cr4).
>around and such like. Mac and PC are doing better than Acorn - FACT. Mac and
>PC docs are light years better than anything I have seen from Acorn (exclude
>Impression manual which actually seems to be genuinely good). Take a hint...
You HAVE to be joking. Acorn documentation is, on the whole, second to none.
The quality of the user guides and technical reference manuals is excellent -
far better than any guides I've ever received with a PC. Perhaps Apple
guides are as good, maybe better, but that doesn't detract from the overall
quality of Acorn documentation.
The C manual is the only exception I can think of. The Impression manual,
which has nothing to do with Acorn, is also pretty dreadful IMHO.
Cheers
Bob
Simon Glass
[Well we're all very sorry Jamie. Truely sorry. We will all try to do better
next time. Do let us know what you think.]
I don't agree with you there. The docs for Desktop C are very good. The docs
for RISC OSlib are also very good, although they do assume you have read the
style guide. Of course RISC OSlib itself leaves much to be desired, but you
can hardly blame the documentation people for all those interdependencies &
limitations.
--
Views expressed not necessarily my own Simon Glass
(sig line withdrawn due to
repetitveness)
Colin Smale
Borlands, some Unix suppliers. The documentation is often written by
so-called Technical Writers, whose primary skill is with the English
(or other) language and who have precious little affinity with the
ultimate END-USERS of what they produce. Hence the tear-out cards in
manuals inviting feedback on the documentation.
Manuals are usually based on information provided by the developers
of the software, who are also too far removed from the END-USERS to
be able to imagine they are one.
Manuals are sometimes regarded as a 'necessary evil' by suppliers.
Too often they emphasise the user-friendliness of the software to
cover up the poor written documentation. They cost a lot of money to
write and to produce, whereas the software itself costs very little
to produce (the manufacturing costs of floppy, box etc).
The result is too often a manual which:
* is more-or-less factually correct;
* has poor indexing;
* has poor cross-referencing;
* has inconsistent assumptions about prior knowledge of the reader;
* is able to answer complicated questions but leaves you stranded
if you have a simple question.
I work with various Unix and Windows development products.
Thankfully I very rarely have to resort to Microsoft's and Borland's
written documentation. One good point about Windows is it's on-line
help system. But if I a user has a simple question like 'I have a
DOS program which I would like to give a windows front-end to; where
do I start?' he'll be reading manuals for six months and still be none
the wiser.
Acorn's hard-copy documentation is IMHO on a par with the others. But
it's only the Windows hypertext help system which makes the information
accessible and useful. If only Acorn had such a system it would make a
BIG difference. StrongHelp is a big step in the right direction, but I'd
want ALL the RISC OS and C information on-line, with SUBSTANTIAL cross-
referencing.
Acorn's indexing is pretty poor. OK, I can use the separate index to find
what I want (sometimes at least), but if I am looking at for example
Wimp_CreateWindow and I want to look at Wimp_LoadTemplate, why should I
be forced to go back to the separate index volume? Can't the syscalls
be in alphabetical order? Can't there be a table of contents at the
start of each chapter? Can't the page numbers start at 1 for each new
chapter? Can't they publish an addendum from time to time?
That was FAR more than I'm entitled to for $0.02 :-)
Colin Smale
--
Snail-mail: Colin Smale, Spechtenkamp 87, NL-3607 KE Maarssenbroek, NL
Tel.: +31 3465 69038 (voice)
E-mail: co...@integrity.nl
Gothick
>Well I think most software documentation stinks. Acorn's, Microsoft's,
>Borlands, some Unix suppliers. The documentation is often written by
I'd agree with all but one of these - Borland's documentation, I think, is
excellent. Where the quality occasionally lacks in some of the reference
sections, just how many people supply a complete C/C++ intro tutorial with
their compilers? Also, the simple value for money: being a registered
customer I got the last copy of C++ I bought for less than #50, including
close on 1000 pages of pretty good documentation.
The other manufacturers' documentation, I would agree, leaves a lot to be
desired ;-)
Matt, and no I don't work for them *grin*
--
Matthew B. M. Gibson: ___
got...@dcs.warwick.ac.uk - cs...@csv.warwick.ac.uk \X/
"Great. I'm a million miles from home, about to be killed, with a
gung-ho iguana who tells me to relax"
Jan M. Faber
b...@cryton.demon.co.uk writes:
>You HAVE to be joking. Acorn documentation is, on the whole, second to
none.
>The quality of the user guides and technical reference manuals is
excellent -
>far better than any guides I've ever received with a PC. Perhaps Apple
>guides are as good, maybe better, but that doesn't detract from the
overall
>quality of Acorn documentation.
I have used Acorn documentation (PRM's), Apple (the Inside Macintosh
range), and a lot of PC stuff and IMHO Acorn really has very good
documentation on paper. However you can, for example, buy most Apple docs
in (sort of a) hyper card format and this really makes them much faster
and easier to use than anything else on paper. A feature I like very much
in both Borland C and Symantec's Think Reference is that you can copy
little program fragments (and they've got a lot of those) right from the
documentation into your code.
Also Symantec is not Apple and Borland is not MS so there is no reason
why another company than Acorn couldn't make this interactive
documentation. Who wants to type in the PRM's?
JM
Jim Noble
>Also Symantec is not Apple and Borland is not MS so there is no reason
>why another company than Acorn couldn't make this interactive
>documentation. Who wants to type in the PRM's?
>JM
Nobody when it has already been done! You can get almost all the Acorn
Technical Publications on one CDROM for #99. The only thing is won't do is
print out more than a single page.
Has anyone got one of these CD ROMs?
Jim
--
Jim Noble
What I just said is probably wrong.
Heck! Everybody knows I only open my mouth to change feet.
Andrew Roberts
>In article <293a2c$m...@unicorn.ccc.nottingham.ac.uk>,
> rs...@unicorn.nott.ac.uk (D.Pead) writes:
>>In article <1993Oct8.0...@waikato.ac.nz> j...@waikato.ac.nz writes:
>>>standard (ie.. Macintosh or PC equivalent, NOT Acorn) then I would consider
>>>buying your compiler, but otherwise, I don't give a sh*t.
>>>
>>Now let's get specific here - the Acorn documentation for RISC-OS lib
>>is poor (but then, so is RISC-OS lib itself!) - I've got no quarrel
>>with the compiler documentation. I suspect that, if Acorn had just
>>thrown in some straight SWI veneers (SWIs being good enough for all
>>those BASIC and assembler programmers out there), then their compiler
>>would have come in for less stick.
>
>I'd disagree -- RISC_OSlib is a praiseworthy attempt at an event-driven
>interface to the RISC OS Window Manager, with object-oriented overtones.
>(It's a shame that subclassing windows came in release 4, but then...) It's
>needed some patching up (about 15000 lines worth last time I looked at
>my source) but the ideas are sound. I think that any system that makes
>it easier to write a multidocument editor than a single document one
>deserves a small measure of credit to go to the designers. The docs
>are adequate, although I'd have preferred the printed docs not
>to be just a rehash of the header file comments, and maybe some hypertext
>docs would be nice. (Compared to the docs supplied with the now venerable
>Beebug C Development System, Acorn's description is truly marvellous,
>although that ain't difficult.)
>
a brief documented example of each header file. As i've just spent 3 weeks
pulling my hair out trying to get the 'Text' library to work, only to find
that it was not my code but the type of template used. This is a prime example
of Acorn explaning the function of a library, but not providing any information
on how to incorporate the libraries into a program.
Or even better how about somone producing a book on how to program the WIMP
in C, as I would now be one of the first customers. Or better still a kind
harted programer out there produce a collection of example programs and post
them to the net.
Andy
--
Andy
###############################################################################