HDTenEightyP/NetNews huggingface dataset:
From: kjetilho@ifi.uio.no (Kjetil Torgrim Homme)
Newsgroups: comp.sys.acorn
Subject: Re: Yes, more .....
Date: 6 Oct 92 08:10:43 GMT
Organization: Dept. of Informatics, University of Oslo, Norway
Originator: kjetilho@holmenkollen.ifi.uio.no

In article <1992Oct6.005201.17970@cs.utwente.nl> kortink@cs.utwente.nl (John Kortink) writes:
   torbenm@diku.dk (Torben AEgidius Mogensen) writes :

   >Also, if an integer divison instruction or 32x32-> 64 bit multiplication
   >are added, use of these will make new code a lot faster than old code
   >that uses subroutines or macroes.  A compiler will automatically use the
   >new instructions.

   And the ARM coder will replace his BL <macro> with the new instruction.
   There's no difference here ...

Yes there is a difference. When you're using macros, you have to have
spare registers in which to put temporary results. After your
search-and-replace, you will have unused registers. A compiler would
never do this mistake. It would use the new registers with glee.

   Quite the contrary. An assembler coder will have optimized code all
   around, because it is all written by him. A compiler can only optimize
   locally, i.e. knit together BL <somewhere>:MOVS PC,R14, and do some
   register optimizations.

Not true, there are compilers that can optimize away whole function
calls, even if the function is defined in a separate c-file.

   The assembler coder furthermore is ideally suited to use real human
   intelligence in optimizing the critical routines. That's the fun of it
   after all.

How can e.g. CC know where to optimize Impression? It is not trivial.
If you program in C, you can use prof to see what procedures use most
CPU, gets called most often etc. (Perhaps this point is moot, because
I don't know whether prof is available under RISC OS :-)

I was a firm believer that assembly was better than HLL before 
 - I saw the output of a proper optimizing compiler.
 - I started using lots of different architectures (VAX, Intel,
   Motorola, SPARC, HP-PA) on a daily basis.

Still, it is important that the programmers know how their machines
work, and do as much as they can to give the compiler a hint. For
example, a program I wrote on my BBC A3000 used the construct (var %
16), and out of curiousity, I checked what the machine code generated
was. To my amazement, it didn't just do (var AND 15), but did some
weird checking. (var % 16) != (var AND 15) for negative var. So I
changed the declaration of var from int to unsigned int, and sure
enough, the compiler did the obvious thing. It was a lesson to me,
anyway :-)

Oh, and I am thankful that there are so many assembly junkies using
the Acorn range of RISC OS computers. I think owners of said range of
machines (boy, I'm feeling pC today :-) are the only ones that care
about RAM and CPU use these days.


Kjetil T.
Newsgroups: comp.sys.acorn
From: ph10@cus.cam.ac.uk (Philip Hazel)
Subject: Re: Oh no ! More .....
Organization: University of Cambridge Computing Service
Date: Fri, 2 Oct 1992 08:56:47 GMT

More information to throw on the fire:

I maintain a screen-oriented text editor which runs on the following platforms:

o   IBM mainframe, MVS operating system (SSMP & 3270 terminals)
o   Several flavours of Unix, including SunOS & Ultrix (SSMP & termcap
    terminals)
o   VAX/VMS (SSMP & VTxxx terminals)
o   Acorn's RISC OS (& previously Arthur & previously the ARM development
    system), though not as a WIMP application
o   Panos (Acorn's OS for 32016-based Acorn Cambridge Workstation - never
    really took off as a machine)
o   MS-DOS

The editor is written in a high level language (BCPL actually, rather than C,
though it is due for a rewrite in C). There is *no way* I could have got it
onto all these platforms had it been written in Assembler. The quickest port
was from Panos to ARM/Arthur - because of the upwards compatibility with the
old Beeb I/O system for screen control, it was almost no work at all.

[The program is not entirely in BCPL: there are small Assembler modules for the
IBM mainframe version and for MS-DOS, where complete accessibility to the OS
is not available from BCPL. None of Acorn's operating systems have ever
suffered from this defect.]

My own position is "horses for courses". Assembler has its place, so do high
level languages. It all depends how you see the tradeoffs in each case.

--
Internet: P.Hazel@ucs.cam.ac.uk       University Computing Service,
JANET:    P.Hazel@uk.ac.cam.ucs       Computer Laboratory, Pembroke St,
Phone:    +44 223 334714              Cambridge CB2 3QG, England.
Newsgroups: comp.sys.acorn
From: kortink@cs.utwente.nl (John Kortink)
Subject: Bugs, Bollocks and the truth about RO3.1
Organization: University of Twente, Dept. of Computer Science
Date: Thu, 1 Oct 1992 22:35:46 GMT

banksie@khantazi.welly.gen.nz (Philip R. Banks) writes :

>   Do other people remember a certain prat talking about a bug in RO 3.10
>regarding menu clicking on the Info window of the Task Manager? Well I did
>and when I was helping, well watching, a friend upgrade the A5000 we use
>with 3.10 I decided to check on the validity of this claim. Low and behold
>the bug refused to manifest itself.

Maybe it has moved :-).

>   Now this really gets my goat as a direct result of this 'rumour' being
>started a great discussion about the 'bugs' of RO 3.1 resulted. And the
>funny thing is none of the alleged bugs reported thus far by these rumour
>mills has been verified.

I agree with you basically, but two bugs (sorry features) were in fact
acked by Acorn : a) slower 'feel' of desktop, mainly filer windows (reason:
more background bandwidth) b) the CSD problems with paths including $
(reason: hacky or inconsistent attempt to unite all these FS's on semantics
(or rather lack of it) of $).

>   So why am I griping about this? To ask people who are thinking of
>spreading these rumour could they actually spend a whole thirty seconds
>actually *checking* them out? It would make this group a whole lot more
>pleasant to use...

Agreed. It gets on my nerves too when bugs seem unfounded in the end.

>   Finally after having seen Risc OS 3.10 I want to congratulate Acorn on a
>job well done. Not is Risc OS 3.10 *not* slower than 3.0 it is infact
>faster.

Oops, why do you start one yourself now ? It was already admitted by Acorn.
It's a matter of accuracy : not the whole of RO3.1 is less fast, the filer
windows are. Frankly, I'm totally used to it now. It does not matter.

>Also for those who want a laugh take a template editor and examine the
>'power' template in the Switcher's resource directory...

Good one :-).

>P.S. So when is Risc OS 4 coming out? :-)

What's that ? ;-)


John Kortink

Student of Informatics at the University of Twente, The Netherlands
(God, will I ever stop doing things 'on the side' and get it done?)
NETMAIL : kortink@cs.utwente.nl              DISCLAIMER : the usual
From: r_voisey@csd.brispoly.ac.uk (R Voisey)
Newsgroups: comp.sys.acorn
Subject: Re: AKJ03 - Risc OS PRM
Date: 6 Oct 92 10:40:02 GMT
Organization: Bristol Polytechnic, England

In article <19156@acorn.co.uk> pcolmer@acorn.co.uk (Philip Colmer) writes:
>NO! An Archimedes keyboard is NOT guaranteed to work. Apparently, BBC
>Acorn User tried it and it seemed to work, but the port on the A4 is
>only intended for use with an IBM keyboard.

Err...  are you saying that BAU plugged an ARCHIMEDES keyboard into
the PC KEYBOARD socket of an A4 and it WORKED???   That's impressive..
the A4 must have some kind of soft switching of the pinouts as well
as auto detection of the COMPLETELY & UTTERLY DIFFERENT hardware &
software protocols.

Bob



-- 
  Robert J. Voisey  :  r_voisey@csd.brispoly.ac.uk
         -- Probug Software Developments --
162 Staplehill Rd, Fishponds, Bristol, Avon, England
From: gtoal@ibmpcug.co.uk (Graham Toal)
Newsgroups: comp.sys.acorn
Subject: sparc file decoder source in C? (for unix)
Date: 27 Sep 92 20:03:04 GMT
Organization: The IBM PC User Group, UK.

I've been given a Sparc archive (stored files only, no compression)
by someone who couldn't write tar files.  Anyone got any code to
decode it on unix (I was about to say 'on a sparc' but thought that
would be too confusing :-) )  Pref. C source.  Or do I have to start
dumping the files to work out what's in them?

Thanks
Graham
-- 
Xref: sparky comp.sys.acorn:8946 comp.sys.acorn.advocacy:160
From: julian@bridge.welly.gen.nz (Julian Wright)
Newsgroups: comp.sys.acorn,comp.sys.acorn.advocacy
Subject: Re: Yes, more .....
Date: Mon, 5 Oct 1992 14:52:07 +1200
Reply-To: wright_j@kosmos.wcc.govt.nz
Followup-To: comp.sys.acorn.advocacy
Organization: USS Enterprise, NCC 1701a

goodwin@edieng.enet.dec.com (Pete Goodwin) writes:

[large chunk of double-quoting deleted]

Argh! Please, Pete, if you're going to quote, delete the sections of
text you are not referring to! My newsreader tells me your posting was
7412 bytes in length, 6249 of which consisted of quoted lines! Some of
us get our news feeds by slow-canoe y'know... (ie modem)

As for the C vs ARM brawl, I think that people should write code in
whichever language they prefer, so long as the application that results
is functional.

Then let the general public decide which applications they prefer.

I could cite something about how Acorn DTP was quick to the market and
just as quickly dropped when Impression turned up, but then somebody
could probably accuse me of taking sides. :-)

Note: Followups to c.s.a.advocacy. Something which should have been done
*ages* ago...

    Cheers, Julian.
    
Newsgroups: comp.sys.acorn
From: bhotvedt@gollum.uio.no (Tor Houghton)
Subject: Re: ReadNews 0.21 is on it's way
Followup-To: comp.sys.acorn
Organization: ArcEmpire
Date: Wed, 30 Sep 1992 01:11:23 GMT

How about FTPing it somewhere?

Cheers,

Tor.
From: mjw19@cl.cam.ac.uk (M.J. Williams)
Newsgroups: comp.sys.acorn
Subject: Re: Gnu C compiler availability query
Date: 3 Oct 92 20:58:13 GMT
Reply-To: mjw19@cl.cam.ac.uk (M.J. Williams)
Organization: The National Society for the Inversion of Cudddly Tigers

In article <26520@castle.ed.ac.uk> sandy@festival.ed.ac.uk (Sandy Nicholson) writes:
>A quick question (which is not on the FAQ list as far as I can make out):
>
>Is there a public domain C compiler available for RISCOS (specifically,
>for the A5000)? I have heard mention on the odd occasion of the FSF
>compiler `gcc' being available, but I have been unable to locate it in
>any of the FTP archives I know of (I am of course unable to compile the
>`gcc' source---otherwise I wouldn't be looking for a C compiler :-> ).

  gcc is available under Risc Ix, indeed I believe it is one of the FSF
  supported architectures. Most gnu ftp sites should carry it. Try using
  archie or something similar.

>On a completely unrelated topic (much discussed of late), I was told by
>my dealer that RISCOS 3.1 ROMs were not yet available---this was a week
>or two ago---and that the upgrade (from 3.0) would cost in the region of
>75 pounds! Any comment?

 Risc OS 3.10 is "available" for Risc OS 3.00 owners for L20. However,
 supplies appear to be a bit slow...

_______________________________________________________________________________
 \   ^   / Michael Williams                     Part II Computer Science Tripos
  |\/|\/\  MJW19@phx.cam.ac.uk                          University of Cambridge
  |  |(__) Cymdeithas Genedlaethol Traddodiad Troi Teigrod Mwythus Ben I Waered
Newsgroups: comp.sys.acorn
From: kortink@cs.utwente.nl (John Kortink)
Subject: Re: Oh no ! More .....
Organization: University of Twente, Dept. of Computer Science
Date: Fri, 2 Oct 1992 12:51:27 GMT

Gavin.Flower@comp.vuw.ac.nz (Gavin Flower) writes :

>???   I always thought that "generally", meant "most, but not all" -
>      am I mistaken   ???

It was all a big mistake on your side then. So you do agree that it
doesn't always have to be C ? Finally we all agree on something then.
Which must be a first on c.s.a.. (Where's the cake ?)

>However, the main principle, is that major applications are usually
>best written in a high level language, so that they can readily be
>adapted to new processors as they come out - a portability issue, if
>if restricted to ARM and Risc-OS.  Once a compiler is available that
>has support for the new processor built in, *all* programs written in
>that language, can be recompiled to make use of its architectural
>innovations (where relevant).  However, every single assembler program
>would have to have varying degrees of work required - just look at
>what is involved in going to make use of the 32 bit mode, in the
>ARM6xy!!

Well, tell us all. These major changes and things-to-be-made-use-of in
the new processors. My guess is that most improvements are speed-wise,
i.e. not requiring any code-level changes at all. Moving from a 26-bit
model to 32-bit would not entail any effort at all for rewriting ARM
code sources. New instructions ? Why use them unless for even further
optimization of an already mega-fast application ?

>There are also a lot of additional issues that mandate the use of high
>level languages for large projects that are designed to be supported
>for many years.

And I say it's bullshit. CC has *proven* this argument to be wrong. That
is what I meant by C-blindness, this really weird concept of using a
high-level language, not after a thorough evaluation of time scales,
investments and priorities, but a-priori.

>Still other issues relate to potentially wider market penetration on other
>platforms.

What other platforms ? What major native Archimedes program would ever need
to be ported to a PC or Amiga ? The portability of C is not at all relevant
to native programs, it's only relevant to big lumpy chunks of straight in
straight out code.

John Kortink

Student of Informatics at the University of Twente, The Netherlands
(God, will I ever stop doing things 'on the side' and get it done?)
NETMAIL : kortink@cs.utwente.nl              DISCLAIMER : the usual
Newsgroups: comp.sys.acorn
Subject: Re: !Palette file internals
From: banksie@khantazi.welly.gen.nz (Philip R. Banks)
Date: Fri, 2 Oct 1992 17:56:22 +1200
Reply-To: banks_p@kosmos.wcc.govt.nz
Organization: My Arc.

gpcec@westminster.ac.uk (Tom Kirby-Green) writes:

> 
>         Where can I find out the internal structure of a !Palette file (
> as produced by !Paint and the Desktop etc ). It seems to be 120 bytes long.
> Does it contain words as returned from OS_ReadPalette? If a 16 colour sprite
> contains 2 * 16 words ( = 128 bytes ) in its "Palette Area", why does the
> !Palette file contain "only" 120? Or are they different internaly?
> 
>         Thanks for you help. Is it me, or is there no mention of !Palette 
> files in the PRM?

   It is a series of VDU 19 codes and can be fed straight into the VDU
stream to use it. (I beleive this is what Palette does anyway.) So each
colour will have at least 5 bytes associated with it...

    Philip

--
Philip R. Banks  Syntax: mail < banks_p@kosmos.wcc.govt.nz >            @@@@@/|
                                                                        @@@@/#|
                                                                        @@@/##|
I have consulted all the sages I could find in the Yellow Pages,        @@/---|
But there aren't many of them. ---A.P.P.                                @/    |
Newsgroups: comp.sys.acorn
From: pmoore@cix.compulink.co.uk (Paul Moore)
Subject: Tabs and !Edit
Reply-To: pmoore@cix.compulink.co.uk
Date: Sun, 27 Sep 1992 11:15:00 +0000


In hos posting, gpcec@sun.pcl.ac.uk (Tom Kirby-Green) says:
 
  > Heres a quick question. When ( using C ) you create a text
  > file containing TAB chars ie; 
 
  > fprintf ( fp, "blah, blah \t blah\n" ); 
 
  > How come you have to use the "Expand Tabs" option in !Edit
  > to expand these?  Does !Edit somehow mark the file as
  > expanded, or what? 
 
Simple answer: !Edit does not consider a tab to be a printable character, so
it displays it using the [09] form. I consider this a bug in edit (it's
certainly a right pain).
 
If you want to display files in !Edit, don't use tabs. Alternatively, if you
want tabs to work properly, don't use !Edit (or !SrcEdit - anybody know
about !DeskEdit?)
 
Gustav.
From: lithgow@usl.com (Malcolm Lithgow)
Newsgroups: comp.sys.acorn
Subject: Re: 'volatile' in Norcroft/Acorn C
Date: 1 Oct 92 02:09:39 GMT

[In message "Re: 'volatile' in Norcroft/Acorn C", Mark Taunton writes:]
>Clive Jones writes:
>>It would be very nice if the compound assignment operators (+=, -=,
>>*=, etc.) were atomic if applied to volatile variables. The obvious
>>way to achieve this would be using SWP, 
>
>How?  Sorry to disappoint, but the SWP instruction (as its mnemonic
>suggests) implements the swapping of data between memory and
>registers, atomically (see below for details).  It doesn't implement
>atomic register-to-memory operations of any other sort.  Regretably,
>then, there is no obvious way to implement what Clive requests: the
>SWP instruction itself cannot be used to do it.  
>
>The nearest thing I can think of is to use SWP to implement
>synchronisation interlocking (using spin-locks) around the required
>("critical region") code sequences.  But this is only applicable for
>inter-processor interlocks, it does not prevent interrupts from
>getting in in the middle of an operation on a single processor.

[ Stuff deleted ]

If it was necessary to have atomic operations for +=, -=, etc. then
surely the only thing that the Norcroft compiler would have to do is
mask interupts around the operation.

I'm not sure why SWP is even mentioned in this discussion since it is
only needful for multi-processor shared-memory systems (even if the
memory shared is only a tiny block of spin-locks).  I'm pretty sure the
Norcroft compiler only compiles for a single processor, and I'm equally
sure that MP Arch's don't exist yet (commercially, at least).

Simple, eh?

-Malcolm.  lithgow@usl.com  These are merely my opinions.
Newsgroups: comp.sys.acorn
From: jkreyka@cs.vu.nl (Kreijkamp J)
Subject: Re: Oh no ! More .....
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam
Date: Mon, 5 Oct 1992 16:31:48 GMT

I haven't followed the whole discussion, but I'm getting the feeling
this discussion should have been about 20 years ago...

Why?
   In those days programs where a lot shorter, compilers slow, and
   the languages badly defined and standarised. But nowadays the have
   many advantages over assembler and only a few minor disadvantages:

 - High level structures.
   Assembler doesn't support proper data-structures, type checking,
   or (to follow the current flow) objects.
   Ever written programs >= 10k lines? (in ansi-C)
   At least I don't want to write this lengthy progs in assembler...
   ...and certainly I don't want to debug one!

 - Portability.
   What if you want to port your very succesful prog to another system?
   What if Acorn decides to change to ARM600 series?
   Yes, these are backwards compatible, but if the OS use the 32bit mode
   (in some very distant future), and uses the 32bit address space completely
   I don't think your code does work very well if it is written in 26bit
   mode. In C (or C++ or whatever you want) you just recompile with the
   new compiler.

 - Standarisation.
   By using standard (C-)libraries your company can force people to use
   standard interfaces, possibly shared-libraries, etc.
   Also it is more easy to reuse code.

 - Readability.
   Very often other people should be able to read your code too,
   for making extensions, and fixing bugs.

 - Tools.
   For the most modern computer languages are good tools for developping
   and debuging. I haven't seen many for Assembler.

 - Etc.
   Go to your library and look for example by the subject software
   engineering.


Assembler only wins in

 - Speed.
   but nowadays compilers have very good optimalisation, and processors
   are faaaaastttt....

 - Size.
   Again there are good compilers which optimise very good, and the
   shared-libraries concept (like CLib on the arch) can reduce code
   size dramaticaly in a multiprocess environment (RiscOs apps)

So in _my_ opinion assembler should not be used or only for writing
very short time critical routines.

Let's hope Acorn builds

  - A good (bugless) C++ compiler
  - A good debugger (compatible with the C++ compiler)
  - A fast computer using 32-bit address space
  - A new and better version of RISCOS supporting this
  - Etc....


(Going to eat now)

Greetings,
	Jaap
Newsgroups: comp.sys.acorn
From: kortink@cs.utwente.nl (John Kortink)
Subject: Oh no ! More .....
Organization: University of Twente, Dept. of Computer Science
Date: Thu, 1 Oct 1992 10:33:27 GMT

Gavin.Flower@comp.vuw.ac.nz (Gavin Flower) writes :

>In article <BvEoDy.3C2@newcastle.ac.uk> Oliver.Cornes@newcastle.ac.uk (Ollie
>W Cornes) writes:
>>I came across this in Eureka, the magazine for the ARM Club...
>>
>>"It is generally accepted that C is the language to use if you intend to
>>write a serious application of any complexity"
>>
>>Not meaning to pick too many holes or anything, but the two main
>>'Serious applications of any complexity' on the Arc, namely Impression
>>and ArtWorks are both written entirely in Assembler.
>
>They did say "generally accepted".
>
>Also, how well do you think these two packages could be adapted to
>take into acount the features of the newer ARM chips?  How will they
>cope with using the 32 bit address mode?  Not to mention some of the
>newer instructions that could well speed up or enable new features.

God no, not *again* ! If anything the ARM code program could cope
*much* easier with this change because it is written in the same
language and the source can be updated in no-time. For a C source,
an entirely new C compiler would have to be written. Guess which
takes longer ? And take another guess at which will be faster and
more memory-efficient ?

>Also, how easily can they incorporate compliance to new features of
>the operating system?

Dead easy, same argument as above.

>These are just some of the motivations for using "C" for "'Serious
>applications of any complexity' on the Arc".

In the meantime, Gavin, Impression and ArtWorks are/will be probably
the best and most widely used applications on the Archimedes. How much
does it take to cure C-blindness ?


John Kortink

Student of Informatics at the University of Twente, The Netherlands
NETMAIL : kortink@cs.utwente.nl              DISCLAIMER : the usual
Newsgroups: comp.sys.acorn
From: melis@fys.ruu.nl (Angelo Melis)
Subject: Re: Oh no ! More .....
Organization: Physics Department, University of Utrecht, The Netherlands
Date: Mon, 5 Oct 1992 12:15:00 GMT

In <1992Oct5.091918.3316@news.uni-stuttgart.de> zrzm0111@helpdesk.rus.uni-stuttgart.de (MUFTI) writes:

>In article <BvIIAt.B3G@comp.vuw.ac.nz> Gavin.Flower@comp.vuw.ac.nz (Gavin Flower) writes:

>>For super large projects, consider ADA, but the Archimedes range,
>>currently isn't bigger enough to get into this territory.  Also there
>>isn't even a hint of an ADA compiler for the Arc.

>There is a hint 8-), but not a port 8-( ...
>On Unix-workstations and MSDOS-PC's there is a usful translator/executor
>for ADA named ADAED. It is currently not validated (but was valitated 
>earlier). It is written in C and could maybe compiled on the Acorn 
>Archimedes (if someone can compile the 20MB source code ...).
>The other question is how much RAM memory it would require .... 

>so long
>MUFTI

Hi,

Because MUFTI posted this message I must send my message also. 8^)
Before everybody starts to download ADAED and start a port of it.

I started last weekend with the port of ADAED. At the moment the library
viewer and the "compiler" are finished (but I haven't tested them yet
very well, so I can not say that they work as intented). These two
programs where n't that difficult to compile, but I think the problems
will come with the executor. But most of it should work without major
rewrite of the code.

I have only time to do some programming in the weekends (because my
Archie stands at home, and I am at the university, so it will take some
time before I get it too work. 

Of course if someone else wants to start with the port, go ahead.

Bye,
Angelo

email : melis@fys.ruu.nl