Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1817 > unrolled thread

Alignment exception examples

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Alignment exception examples druck <news@druck.org.uk> - 2012-06-23 20:55 +0100
    Re: Alignment exception examples chrisbazley@bigfoot.com - 2012-06-23 13:21 -0700
      Re: Alignment exception examples druck <news@druck.org.uk> - 2012-06-24 11:35 +0100
        Re: Alignment exception examples chrisbazley@bigfoot.com - 2012-06-24 04:02 -0700
          Re: Alignment exception examples druck <news@druck.freeuk.com> - 2012-06-24 17:29 +0100
          Re: Alignment exception examples Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-06-26 00:02 +0100
            Re: Alignment exception examples chrisbazley@bigfoot.com - 2012-06-26 01:15 -0700
              Re: Alignment exception examples Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-06-26 11:51 +0100
                Re: Alignment exception examples chrisbazley@bigfoot.com - 2012-06-27 05:40 -0700
                  Re: Alignment exception examples druck <news@druck.org.uk> - 2012-06-27 22:43 +0100
              Re: Alignment exception examples Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-06-26 14:06 +0100
              Re: Alignment exception examples druck <news@druck.org.uk> - 2012-06-26 21:57 +0100
                Re: Alignment exception examples Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-06-26 23:20 +0100
                  Re: Alignment exception examples druck <news@druck.org.uk> - 2012-06-27 22:51 +0100
                Re: Alignment exception examples chrisbazley@bigfoot.com - 2012-06-26 15:17 -0700
                  Re: Alignment exception examples Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-06-27 00:23 +0100
                    Re: Alignment exception examples chrisbazley@bigfoot.com - 2012-06-27 05:52 -0700
                      Re: Alignment exception examples druck <news@druck.org.uk> - 2012-06-27 22:46 +0100
                      Re: Alignment exception examples Nick Roberts <tigger@orpheusinternet.co.uk> - 2012-06-28 18:28 +0100
                        Re: Alignment exception examples Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-06-29 18:38 +0100
                          Re: Alignment exception examples Nick Roberts <tigger@orpheusinternet.co.uk> - 2012-06-29 20:14 +0100
                      Re: Alignment exception examples druck <news@druck.freeuk.com> - 2012-07-04 20:50 +0100
                  Re: Alignment exception examples spampling <spam.pling@btinternet.com> - 2012-06-27 07:58 +0100
                    Re: Alignment exception examples chrisbazley@bigfoot.com - 2012-06-27 05:44 -0700
                      Re: Alignment exception examples spampling <spam.pling@btinternet.com> - 2012-06-27 18:13 +0100
                      Re: Alignment exception examples druck <news@druck.org.uk> - 2012-06-27 22:47 +0100
                  Re: Alignment exception examples druck <news@druck.org.uk> - 2012-06-27 23:04 +0100
                    Re: Alignment exception examples chrisbazley@bigfoot.com - 2012-06-28 15:43 -0700
    Re: Alignment exception examples Thomas Milius <Thomas-Milius@t-online.de> - 2012-06-24 08:24 +0200
      Re: Alignment exception examples druck <news@druck.org.uk> - 2012-06-24 11:37 +0100
        Re: Alignment exception examples Thomas Milius <Thomas-Milius@t-online.de> - 2012-06-24 12:49 +0200
          Re: Alignment exception examples druck <news@druck.freeuk.com> - 2012-06-24 17:01 +0100
            Re: Alignment exception examples Thomas Milius <Thomas-Milius@t-online.de> - 2012-06-24 19:16 +0100
              Re: Alignment exception examples "Ste (news)" <steve@revi11.plus.com> - 2012-07-10 00:14 +0100
    Re: Alignment exception examples Steve Fryatt <news@stevefryatt.org.uk> - 2012-06-24 09:42 +0100
    Re: Alignment exception examples Martin <News03@avisoft.f9.co.uk> - 2012-06-27 15:36 +0100

Page 1 of 2  [1] 2  Next page →

#1817 — Alignment exception examples

Hi,

I want to extend ARMalyser's static code analysis engine to report 
potential alignment exceptions in ARMv7 code. Can anyone point me at 
code known to produce alignment exceptions on the Beagle board, so I can 
see if ARMalyser does actually spot them in real code. If possible I'd 
like examples of both data alignment and branches with bit 0 set.

Free software which I can download would be my first preference, but if 
anyone has some of their own code (such as old versions of software 
prior to being fixed), please reply before sending the code so my mail 
box doesn't get full.

---druck

[toc] | [next] | [standalone]

#1818

On Saturday, June 23, 2012 8:55:51 PM UTC+1, druck wrote:
> Hi,
> 
> I want to extend ARMalyser's static code analysis engine to report 
> potential alignment exceptions in ARMv7 code. Can anyone point me at 
> code known to produce alignment exceptions on the Beagle board, so I can 
> see if ARMalyser does actually spot them in real code. If possible I'd 
> like examples of both data alignment and branches with bit 0 set.

I don't believe it is possible to detect misaligned data accesses using static analysis because you can't know what addresses in registers are - only constant shifts, rotations and offsets. I suppose that you could flag instructions such as LDR a1,[v1,v2,LSL#1] as 'likely' to be unaligned data accesses, but it is equally possible that the values of v2 are constrained such that odd values never occur.

I think your best bet would be to look at the code generated by the Norcroft C compiler for 'short int' types, because it was used to compile most RISC OS applications and is presumably responsible for the majority of unaligned data accesses.

The general pattern is the following code, which loads a signed integer halfword regardless of whether Rn is word-aligned or half-word-aligned, provided that <offset> is a multiple of 2:

LDR<cond> Rd,[Rn,#<offset>]
MOV<cond> Rd,Rd,LSL #16
MOV<cond> Rd,Rd,ASR #16

Someone clever could probably use the AppPatcher mechanism to substitute:

LDR<cond>SH Rd,[Rn,#<offset>]
MOV R0,R0
MOV R0,R0

That would break compatibility with older ARM architectures, but if the patching were done at run time, that wouldn't matter, right?

Of course, for programs such as Star Fighter 3000 which use runtime code generation, static analysis would be useless.

I still think recompiling all RISC OS software is a futile cause, despite having grudgingly invested several weekends in Schema 2 and its peripheral applications so that someone can carry on using the same spreadsheet application they've been using for about a quarter of a century.

Chris Bazley

[toc] | [prev] | [next] | [standalone]

#1822

On 23/06/2012 21:21, chrisbazley@bigfoot.com wrote:
> I don't believe it is possible to detect misaligned data accesses
> using static analysis

It is not possible to spot ALL misaligned access, but it is possible to 
spot some.

> because you can't know what addresses in
> registers are - only constant shifts, rotations and offsets.

ARMalyser can already work out what some register contents are from 
immediate values, loads from absolute or PC relative addresses, and 
subsequent arithmetic instructions and and write backs. Use the -r 
option to see.

> I
> suppose that you could flag instructions such as LDR a1,[v1,v2,LSL#1]
> as 'likely' to be unaligned data accesses, but it is equally possible
> that the values of v2 are constrained such that odd values never
> occur.

It can certainly any word load/store where the address is altered by a 
non multiple of 4, even where the actual address isn't known.

> I think your best bet would be to look at the code generated by the
> Norcroft C compiler for 'short int' types, because it was used to
> compile most RISC OS applications and is presumably responsible for
> the majority of unaligned data accesses.

The above should spot such code.
>
> The general pattern is the following code, which loads a signed
> integer halfword regardless of whether Rn is word-aligned or
> half-word-aligned, provided that<offset>  is a multiple of 2:
>
> LDR<cond>  Rd,[Rn,#<offset>] MOV<cond>  Rd,Rd,LSL #16 MOV<cond>
> Rd,Rd,ASR #16
>
> Someone clever could probably use the AppPatcher mechanism to
> substitute:
>
> LDR<cond>SH Rd,[Rn,#<offset>] MOV R0,R0 MOV R0,R0

That's beyond the scope of ARMalyser, although it was written to be the 
first set in automatic 32bit porting with a dynamic component like 
Aemulor to come later, but Aemulor got there first.

> That would break compatibility with older ARM architectures, but if
> the patching were done at run time, that wouldn't matter, right?

Correct

> Of course, for programs such as Star Fighter 3000 which use runtime
> code generation, static analysis would be useless.

Yes, but the days of the ARM2 are long gone, dynamic code became 
impractical when the separate caches of the Strong ARM come in.

> I still think recompiling all RISC OS software is a futile cause,
> despite having grudgingly invested several weekends in Schema 2 and
> its peripheral applications so that someone can carry on using the
> same spreadsheet application they've been using for about a quarter
> of a century.

Its the best way unless you want each later generation of ARM processor 
to run existing software slower and more buggierly than the last. 
Especially when native hardware is up against emulators on x86 which can 
run the oldest software perfectly at vastly faster speeds.

---druck

[toc] | [prev] | [next] | [standalone]

#1825

On Sunday, June 24, 2012 11:35:56 AM UTC+1, druck wrote:
> On 23/06/2012 21:21, chrisbazley@bigfoot.com wrote:
> > I don't believe it is possible to detect misaligned data accesses
> > using static analysis
> 
> It is not possible to spot ALL misaligned access, but it is possible to 
> spot some.

Would you use a program that only crashes some of the time?

> > Of course, for programs such as Star Fighter 3000 which use runtime
> > code generation, static analysis would be useless.
> 
> Yes, but the days of the ARM2 are long gone, dynamic code became 
> impractical when the separate caches of the Strong ARM come in.

I expect that's why just-in-time compilation never really took off. Oh, wait...

> > I still think recompiling all RISC OS software is a futile cause,
> > despite having grudgingly invested several weekends in Schema 2 and
> > its peripheral applications so that someone can carry on using the
> > same spreadsheet application they've been using for about a quarter
> > of a century.
> 
> Its the best way unless you want each later generation of ARM processor 
> to run existing software slower and more buggierly than the last. 

I cannot believe that emulating unaligned data accesses would be so detrimental to performance as to cancel out increases in clock speed, and it seems unlikely to make software 'more buggierly' than attempting to execute it on an incompatible architecture and hoping that you've spotted all of the incompatibilities. That approach would only be tenable if you had a complete set of unit tests for every RISC OS application (and by complete I mean providing 100% condition coverage).

> Especially when native hardware is up against emulators on x86 which can 
> run the oldest software perfectly at vastly faster speeds.

There is a solution (full or partial emulation) which runs the oldest software perfectly and fast, which you reject in favour of a solution which requires all software to be recompiled and by your own admission isn't foolproof. I see.

While you're at it, why not lobby for removal of FPEmulator and all software to be recompiled to use the VFP instruction set?

Chris Bazley

[toc] | [prev] | [next] | [standalone]

#1827

On 24 Jun 2012 chrisbazley@bigfoot.com wrote:

> On Sunday, June 24, 2012 11:35:56 AM UTC+1, druck wrote:
>> On 23/06/2012 21:21, chrisbazley@bigfoot.com wrote:
>>> I don't believe it is possible to detect misaligned data accesses
>>> using static analysis
>> 
>> It is not possible to spot ALL misaligned access, but it is possible to
>> spot some.

> Would you use a program that only crashes some of the time?

ARMalyser was designed to aid 32 bit porting by spotting as many of 
the issues as possible, but never guarantees to find all of them, that 
is what the human is for.

[snip]

> I cannot believe that emulating unaligned data accesses would be so
> detrimental to performance as to cancel out increases in clock speed,

Count the cycles to take the exception, fix back up the registers (not 
always possible) and to perform the intended access using 4 byte 
loads, and you are talking a couple of hundred times slower for each 
faulting access, or which there may be many. On the other hand 
recompiling will often use an instruction combination which is either 
faster, or at most 2x the cycles of the original code and probably 
still faster on new processors.

> and it seems unlikely to make software 'more buggierly' than
> attempting to execute it on an incompatible architecture and hoping
> that you've spotted all of the incompatibilities.

Code which produces alignment exceptions is in many cases not entirely 
32bit safe, but "gets away with it" in a manner which is even less 
likely to work as chips evolve. Recompiling for each new generation is 
the only sure way when such drastic evolution of the instruction set 
is taking place.

> That approach would only be tenable if you had a complete set of unit
> tests for every RISC OS application (and by complete I mean providing
> 100% condition coverage).

I doubt if any RISC OS application has been tested to that extent, 
apart from a handfull of bespoke industrial control programs.

>> Especially when native hardware is up against emulators on x86 which can
>> run the oldest software perfectly at vastly faster speeds.

> There is a solution (full or partial emulation) which runs the oldest
> software perfectly and fast, which you reject in favour of a solution
> which requires all software to be recompiled and by your own admission
> isn't foolproof. I see.

But your solution is only an emulation of faulting instructions, where 
as a full machine emulation can take full advantage of far faster than 
native hardware, plus memory and disc caching from the underlying OS, 
which make a vast difference to performance.

> While you're at it, why not lobby for removal of FPEmulator and all
> software to be recompiled to use the VFP instruction set?

If you've got any app which does serious floating point, you'd be mad 
not to recompile. But given that RISC OS has had very poor FP since 
hardware FP was canned, its only going to be ported programs that are 
FP heavy, which means its even easier to recomopile.

---druck

-- 
The ARM Club Free Software - http://www.armclub.org.uk/free/
32 bit Conversions Page    - http://www.armclub.org.uk/32bit/

[toc] | [prev] | [next] | [standalone]

#1829

chrisbazley@bigfoot.com wrote:
> While you're at it, why not lobby for removal of FPEmulator and all
> software to be recompiled to use the VFP instruction set?

Aksherlly, that's not a bad idea.

Compile everything for VFP and expand FPEmulator to cope with those
instructions too.  Old hardware emulates instructions just as slow as it
always has, and new hardware runs a lot faster.  Old apps use FPA
instructions as before.

How about it?

Theo

[toc] | [prev] | [next] | [standalone]

#1830

On Tuesday, June 26, 2012 12:02:08 AM UTC+1, Theo Markettos wrote:
> chrisbazley@bigfoot.com wrote:
> > While you're at it, why not lobby for removal of FPEmulator and all
> > software to be recompiled to use the VFP instruction set?
> 
> Aksherlly, that's not a bad idea.
> 
> Compile everything for VFP and expand FPEmulator to cope with those
> instructions too.  Old hardware emulates instructions just as slow as it
> always has, and new hardware runs a lot faster.  Old apps use FPA
> instructions as before.
> 
> How about it?
> 
> Theo

I think you forgot something: ARM3+FPA, ARM7500FE and emulated machines would boot slower with less free memory and run recompiled apps an order of magnitude slower. How do you think the numbers compare to BeagleBoards running RISC OS?

Chris Bazley

[toc] | [prev] | [next] | [standalone]

#1831

chrisbazley@bigfoot.com wrote:
> I think you forgot something: ARM3+FPA, ARM7500FE and emulated machines
> would boot slower with less free memory and run recompiled apps an order
> of magnitude slower.  How do you think the numbers compare to BeagleBoards
> running RISC OS?

Guesses:
ARM3+FPA: almost nil used these days
ARM7500FE: some A7000+/RiscStations/etc, but relatively few in current use. 
Almost no NCs/etc used these days (lots of early NCs being ARM7500 anyway)
RPCEmu: FPA emulation, but disabled by default due to bugs
VRPC: Is FP implemented?  I can't seem to find any reference to it.

(by 'used' I mean regular use, not 'turn it on every 6 months to charge the
battery' use)

I'm not sure why it would take less free memory, apart from the code for a
bigger emulator (few KB).

In the case of emulators, they could have the VFP instruction set added too. 
Might make for some rather crazy CPU combinations though (ARM2 with VFP,
anyone?)

Theo

[toc] | [prev] | [next] | [standalone]

#1838

On Tuesday, 26 June 2012 11:51:17 UTC+1, Theo Markettos  wrote:
> chrisbazley@bigfoot.com wrote:
> > I think you forgot something: ARM3+FPA, ARM7500FE and emulated machines
> > would boot slower with less free memory and run recompiled apps an order
> > of magnitude slower.  How do you think the numbers compare to BeagleBoards
> > running RISC OS?
[snip]
> I'm not sure why it would take less free memory, apart from the code for a
> bigger emulator (few KB).

Because the emulator would have to be loaded into the relocatable module area instead of using the version in ROM. As you know, RMA bloat is a major problem on older machines because they have less memory.

Chris Bazley

[toc] | [prev] | [next] | [standalone]

#1843

On 27/06/2012 13:40, chrisbazley@bigfoot.com wrote:
> On Tuesday, 26 June 2012 11:51:17 UTC+1, Theo Markettos  wrote:
>> chrisbazley@bigfoot.com wrote:
>>> I think you forgot something: ARM3+FPA, ARM7500FE and emulated
>>> machines would boot slower with less free memory and run
>>> recompiled apps an order of magnitude slower.  How do you think
>>> the numbers compare to BeagleBoards running RISC OS?
> [snip]
>> I'm not sure why it would take less free memory, apart from the
>> code for a bigger emulator (few KB).
>
> Because the emulator would have to be loaded into the relocatable
> module area instead of using the version in ROM. As you know, RMA
> bloat is a major problem on older machines because they have less
> memory.

Most FP using applications that are still being maintained, already 
RMEnsure a far more recent version of FPE than in the ROM of such 
ancient machines, for bug fixes and performance improvements.

---druck

[toc] | [prev] | [next] | [standalone]

#1832

The following bytes were arranged on 26 Jun 2012 by chrisbazley@bigfoot.com:

> I think you forgot something: ARM3+FPA, ARM7500FE and emulated
> machines would boot slower with less free memory and run recompiled
> apps an order of magnitude slower. How do you think the numbers
> compare to BeagleBoards running RISC OS?

At a guess, I'd say about a ratio of one to twenty.  In favour of the
BeagleBoards.

-- 
  __<^>__   "Did you know that polar bears stay white all year round? ...The
 / _   _ \  white colour makes them less visible to the seals and penguins
( ( |_| ) ) they hunt."  - Nelson Thornes AQA-endorsed GCSE science textbook
 \_>   <_/  ======================= Martin Bazley ==========================

[toc] | [prev] | [next] | [standalone]

#1833

On 26/06/2012 09:15, chrisbazley@bigfoot.com wrote:
> On Tuesday, June 26, 2012 12:02:08 AM UTC+1, Theo Markettos wrote:
>> Compile everything for VFP and expand FPEmulator to cope with
>> those instructions too.  Old hardware emulates instructions just as
>> slow as it always has, and new hardware runs a lot faster.  Old
>> apps use FPA instructions as before.
>>
>> How about it?
>>
>> Theo
>
> I think you forgot something: ARM3+FPA, ARM7500FE and emulated
> machines would boot slower with less free memory and run recompiled
> apps an order of magnitude slower.

Do we care about FP performance on extremely old and slow hardware?

All my 32bit conversions broke compatibility with the ARM2/3 due to the 
use of MRS/MSR instructions. I've not had one complaint in the last 6 
years. So I think the RISC OS world can stand a modicum of progress and 
drop support for things produced 3 decades ago.

---druck

[toc] | [prev] | [next] | [standalone]

#1834

The following bytes were arranged on 26 Jun 2012 by druck :

> So I think the RISC OS world can stand a modicum of progress and drop
> support for things produced 3 decades ago.

I think 3 decades is a bit of an exaggeration.  We've only just
celebrated the 30th birthday of the BBC!

-- 
  __<^>__
 / _   _ \  I don't have a problem with God; it's his fan club I can't stand.
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

[toc] | [prev] | [next] | [standalone]

#1846

On 26/06/2012 23:20, Martin Bazley wrote:
> The following bytes were arranged on 26 Jun 2012 by druck :
>
>> So I think the RISC OS world can stand a modicum of progress and drop
>> support for things produced 3 decades ago.
>
> I think 3 decades is a bit of an exaggeration.  We've only just
> celebrated the 30th birthday of the BBC!

ARM3 & FPA were early 90's, we've had the naughties and now were in the 
tennies - so at least spanning 3 decades.

---druck

[toc] | [prev] | [next] | [standalone]

#1835

On Tuesday, June 26, 2012 9:57:41 PM UTC+1, druck wrote:
> On 26/06/2012 09:15, chrisbazley@bigfoot.com wrote:
> > On Tuesday, June 26, 2012 12:02:08 AM UTC+1, Theo Markettos wrote:
> >> Compile everything for VFP and expand FPEmulator to cope with
> >> those instructions too.  Old hardware emulates instructions just as
> >> slow as it always has, and new hardware runs a lot faster.  Old
> >> apps use FPA instructions as before.
> >>
> >> How about it?
> >>
> >> Theo
> >
> > I think you forgot something: ARM3+FPA, ARM7500FE and emulated
> > machines would boot slower with less free memory and run recompiled
> > apps an order of magnitude slower.
> 
> Do we care about FP performance on extremely old and slow hardware?

Well, my sister might because she uses an A5000.

> All my 32bit conversions broke compatibility with the ARM2/3 due to the 
> use of MRS/MSR instructions. I've not had one complaint in the last 6 
> years. So I think the RISC OS world can stand a modicum of progress and 
> drop support for things produced 3 decades ago.

I think it all comes down to what you think RISC OS is for.

It seems that you want to run ported applications as fast as possible on the latest hardware, and to hell with backward compatibility. You don't even seem particularly bothered about executing incompatible code on an operating system that provides minimal safeguards against insidious side-effects.

I don't see the point of that, because you are competing with next-generation operating systems on exactly the same hardware, which I would expect to run the same applications faster and more stable with better control over threads and processes.

I am concerned about the effect of further fragmentation on what remains of the RISC OS 'scene', which is why I have never (and probably will never) compile software for an ISA that isn't compatible with ARM2. I don't think there are enough RISC OS users left to alienate the returnees who buy Acorn machines on eBay.

Chris Bazley

[toc] | [prev] | [next] | [standalone]

#1836

chrisbazley@bigfoot.com wrote:
> It seems that you want to run ported applications as fast as possible on
> the latest hardware, and to hell with backward compatibility.  You don't
> even seem particularly bothered about executing incompatible code on an
> operating system that provides minimal safeguards against insidious
> side-effects.

I'm not sure where 'ported' came from.

For example, Draw uses lots of floating point.  In the grid-drawing code of
all places.  Ever waited for the grid to redraw when zoomed out a long way? 
I bet many people have.  Open and close the menu, time to redraw the grid
again.

Being compiled FPA hard-float (the only way that Norcroft can do it at the
moment), when the grid is redrawn it spends a very long time flitting back
and forth into the undefined instruction handler to execute FPA
instructions...  I don't know how many instructions per grid-point, but it
isn't pretty.

So, compile this code to use an instruction set that actually exists in
processors people have today, and it's a big win (my guess would be factor
of 10 at least).  Simple recompile (think GCC can now build the core apps,
and can do VFP), same app, same workflow, no annoying redraw wait.

> I am concerned about the effect of further fragmentation on what remains
> of the RISC OS 'scene', which is why I have never (and probably will
> never) compile software for an ISA that isn't compatible with ARM2.

Err, that's precisely why I proposed writing a VFPEmulator that will emulate
these instructions on older hardware.  FPASC (the source that builds
FPEmulator) has a build option for RISC OS 3.1, so apparently it can still
be built for ARM2.  It 'just' (ahem) needs support for the extra VFP
instructions adding.

Theo

[toc] | [prev] | [next] | [standalone]

#1840

On Wednesday, June 27, 2012 12:23:49 AM UTC+1, Theo Markettos wrote:
> chrisbazley@bigfoot.com wrote:
> > It seems that you want to run ported applications as fast as possible on
> > the latest hardware, and to hell with backward compatibility.  You don't
> > even seem particularly bothered about executing incompatible code on an
> > operating system that provides minimal safeguards against insidious
> > side-effects.
> 
> I'm not sure where 'ported' came from.

It came from druck, who wrote "But given that RISC OS has had very poor FP since hardware FP was canned, its only going to be ported programs that are FP heavy, which means its even easier to recomopile."

Actually, I don't think it's true that only ported programs are FP heavy. You already gave one counter-example and what about spreadsheets (or anything written in C by someone who wasn't a masochist)?

Chris Bazley

[toc] | [prev] | [next] | [standalone]

#1844

On 27/06/2012 13:52, chrisbazley@bigfoot.com wrote:
> Actually, I don't think it's true that only ported programs are FP
> heavy. You already gave one counter-example and what about
> spreadsheets (or anything written in C by someone who wasn't a
> masochist)?

Heavy FP in spreadsheets is a myth, for every FP instruction used in 
recalculating data, millions of non FP instructions are used to update 
the screen with the result.

---druck

[toc] | [prev] | [next] | [standalone]

#1850

In message <a0861437-d349-4d4f-8188-8e1291a0a3a7@googlegroups.com>
       chrisbazley@bigfoot.com wrote:

> On Wednesday, June 27, 2012 12:23:49 AM UTC+1, Theo Markettos wrote:
> > chrisbazley@bigfoot.com wrote:
> > > It seems that you want to run ported applications as fast as
> > > possible on the latest hardware, and to hell with backward
> > > compatibility.  You don't even seem particularly bothered about
> > > executing incompatible code on an operating system that provides
> > > minimal safeguards against insidious side-effects.
> > 
> > I'm not sure where 'ported' came from.
> 
> It came from druck, who wrote "But given that RISC OS has had very
> poor FP since hardware FP was canned, its only going to be ported
> programs that are FP heavy, which means its even easier to
> recomopile."
> 
> Actually, I don't think it's true that only ported programs are FP
> heavy. You already gave one counter-example and what about
> spreadsheets (or anything written in C by someone who wasn't a
> masochist)?

Well, I don't _think_ I'm a masochist, but...

!Rename : does just 2 fp calculations when redrawing one of its windows
(outside the redraw loop).

BookMaker : double? What's a double?

BDRand : One random number generation, followed by a sequence of fp
comparisones, every time the backdrop is changed.

MakeTable : Not a one.

SprUtils : Not here, either, squire.

ASM : A fair amount actually. But then, it needs to be able to generate
floating point constants, etc.

My entire KISS suite has two areas that use floating point, the first
of which is invoked once during a drag, the second is to support
various randomisation functions in the animation language. It probably
represents something around 0.001% of the executed code.

So no, most stuff written in C isn't FP intensive (unless the person
writing the C doesn't understand the purpose of strong typing).

-- 
Nick Roberts           tigger @ orpheusinternet.co.uk           

Hanlon's Razor: Never attribute to malice that which
can be adequately explained by stupidity.

[toc] | [prev] | [next] | [standalone]

#1851

Nick Roberts <tigger@orpheusinternet.co.uk> wrote:
> So no, most stuff written in C isn't FP intensive (unless the person
> writing the C doesn't understand the purpose of strong typing).

It depends on the domain... a web server or a database won't use much FP, a
CAD package or a video codec will.  For things naturally suited to FP it
gets quite tedious to try to write them using solely integers (especially if
fixed point isn't sufficient).

Theo

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.acorn.programmer

csiph-web