Skip to contentSkip to conversation

arm: add 64-64 bit divider

PATCH New Che-Liang Chiou 5 participants 21 messages Aug 31, 2011 – Sep 20, 2011 Arm (32-bit)

lore
Share & tools
lore

Che-Liang Chiou

author
#0 lore raw

PATCH 1/1 arm: add 64-64 bit divider

This patch adds a 64-64 bit divider that supports ARMv4 and above.

Because clz (count leading zero) instruction is added until ARMv5, the divider implements a clz function for ARMv4 targets.

The divider was tested with the following test driver code ran by qemu-arm:

  int main(void)
  {
    uint64_t a, b, q, r;
    while (scanf("%llx %llx %llx %llx", &a, &b, &q, &r) > 0)
      printf("%016llx %016llx %016llx %016llx\n", a, b, a / b, a % b);
    return 0;
  }
Signed-off-by Che-Liang Chiou <[email protected]>
Cc Albert Aribaud <[email protected]>

---
This patch is alos tested with MAKEALL -a arm

 arch/arm/lib/Makefile    |    1 +
 arch/arm/lib/_uldivmod.S |  266 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 267 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/lib/_uldivmod.S
arch/arm/lib/Makefile +1 -0
index 300c8fa..31770dd 100644
@@ -33,6 +33,7 @@ GLSOBJS	+= _divsi3.o
 GLSOBJS	+= _lshrdi3.o
 GLSOBJS	+= _modsi3.o
 GLSOBJS	+= _udivsi3.o
+GLSOBJS	+= _uldivmod.o
 GLSOBJS	+= _umodsi3.o
 
 GLCOBJS	+= div0.o
arch/arm/lib/_uldivmod.S new file +266 -0

266 lines not on this page · raw message

Signature · 1 line
1.7.3.1
#1 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Quoted 16 lines · Che-Liang Chiou

This patch adds a 64-64 bit divider that supports ARMv4 and above.

Because clz (count leading zero) instruction is added until ARMv5, the divider implements a clz function for ARMv4 targets.

The divider was tested with the following test driver code ran by qemu-arm:

  int main(void)
  {
    uint64_t a, b, q, r;
    while (scanf("%llx %llx %llx %llx", &a, &b, &q, &r) > 0)
      printf("%016llx %016llx %016llx %016llx\n", a, b, a / b, a % b);
    return 0;
  }
Quoted 3 lines
Signed-off-by Che-Liang Chiou <[email protected]>
Cc Albert Aribaud <[email protected]>

---

Hi,

do you see any kind of a performance hit so you can't use the default "C" version?

Cheers

#2 lore raw

PATCH 1/1 arm: add 64-64 bit divider

In reply to Che-Liang Chiou
Quoted 1 line · On Wednesday, August 31, 2011 06:38:50 Che-Liang Chiou wrote:

This patch adds a 64-64 bit divider that supports ARMv4 and above.

why ? if you're doing 64 bit divides, chances are you're doing something fundamentally wrong. perhaps you should fix that instead.

this is also why we have the do_div() helper macro.

so until your changelog documents the actual *reason* for this patch: NAK -mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110831/377ed5eb/attachment.pgp

#3 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Quoted 5 lines · Mike Frysinger
Quoted 1 line · On Wednesday, August 31, 2011 06:38:50 Che-Liang Chiou wrote:

This patch adds a 64-64 bit divider that supports ARMv4 and above.

why ? if you're doing 64 bit divides, chances are you're doing something fundamentally wrong. perhaps you should fix that instead.

Oh come on Mike, what about too big NAND memories ?

Quoted 4 lines

this is also why we have the do_div() helper macro.

so until your changelog documents the actual *reason* for this patch: NAK

The reason is likely it's faster. But I don't think it matters, that's why I commented on this already.

If he's fixing something by this (like I mistakenly did some time ago), there's really something wrong.

Quoted 1 line

-mike

#4 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Quoted 8 lines · On Wednesday, August 31, 2011 11:11:00 Marek Vasut wrote:
Quoted 5 lines · Mike Frysinger
Quoted 1 line · On Wednesday, August 31, 2011 06:38:50 Che-Liang Chiou wrote:

This patch adds a 64-64 bit divider that supports ARMv4 and above.

why ? if you're doing 64 bit divides, chances are you're doing something fundamentally wrong. perhaps you should fix that instead.

Oh come on Mike, what about too big NAND memories ?

Linux hasnt had a problem supporting large NAND without a 64bit divide routine. why are we special ?

Quoted 5 lines
Quoted 3 lines

this is also why we have the do_div() helper macro.

so until your changelog documents the actual *reason* for this patch: NAK

The reason is likely it's faster.

let's see actual #'s
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110831/d8034847/attachment.pgp

#5 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Quoted 5 lines · Mike Frysinger
Quoted 4 lines · On Wednesday, August 31, 2011 11:11:00 Marek Vasut wrote:
Quoted 3 lines · Mike Frysinger
Quoted 1 line · On Wednesday, August 31, 2011 06:38:50 Che-Liang Chiou wrote:

This patch adds a 64-64 bit divider that supports ARMv4 and above.

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

why ? if you're doing 64 bit divides, chances are you're doing something fundamentally wrong. perhaps you should fix that instead.

Oh come on Mike, what about too big NAND memories ?

Linux hasnt had a problem supporting large NAND without a 64bit divide routine. why are we special ?

Because someone (?) has to fix the code that uses do_div() ;-)

Quoted 9 lines
Quoted 7 lines
Quoted 5 lines

this is also why we have the do_div() helper macro.

so until your changelog documents the actual *reason* for this patch:
NAK

The reason is likely it's faster.

let's see actual #'s

True, will you make the measurements? ;-)

Still, I'd stick with the plain-C version, it doesn't matter I guess.

Cheers

Quoted 1 line

-mike

#6 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Quoted 9 lines · On Wednesday, August 31, 2011 11:33:59 Marek Vasut wrote:
Quoted 8 lines · Mike Frysinger
Quoted 7 lines · On Wednesday, August 31, 2011 11:11:00 Marek Vasut wrote:
Quoted 5 lines · Mike Frysinger
Quoted 1 line · On Wednesday, August 31, 2011 06:38:50 Che-Liang Chiou wrote:

This patch adds a 64-64 bit divider that supports ARMv4 and above.

why ? if you're doing 64 bit divides, chances are you're doing something fundamentally wrong. perhaps you should fix that instead.

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

Oh come on Mike, what about too big NAND memories ?

Linux hasnt had a problem supporting large NAND without a 64bit divide routine. why are we special ?

Because someone (?) has to fix the code that uses do_div() ;-)

sure ... the guy with the problem gets to post the fix :)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110831/b70b44dd/attachment.pgp

#7 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Quoted 12 lines · Mike Frysinger
Quoted 11 lines · On Wednesday, August 31, 2011 11:33:59 Marek Vasut wrote:
Quoted 10 lines · Mike Frysinger
Quoted 9 lines · On Wednesday, August 31, 2011 11:11:00 Marek Vasut wrote:
Quoted 7 lines · Mike Frysinger
Quoted 2 lines · On Wednesday, August 31, 2011 06:38:50 Che-Liang Chiou wrote:

This patch adds a 64-64 bit divider that supports ARMv4 and above.

why ? if you're doing 64 bit divides, chances are you're doing something fundamentally wrong. perhaps you should fix that instead.

Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line

Oh come on Mike, what about too big NAND memories ?

Linux hasnt had a problem supporting large NAND without a 64bit divide routine. why are we special ?

Because someone (?) has to fix the code that uses do_div() ;-)

sure ... the guy with the problem gets to post the fix :)

Cool, would that be ... you ? ;-)

Cheers

#8 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Quoted 15 lines · On Wednesday, August 31, 2011 12:30:25 Marek Vasut wrote:
Quoted 14 lines · Mike Frysinger
Quoted 13 lines · On Wednesday, August 31, 2011 11:33:59 Marek Vasut wrote:
Quoted 12 lines · Mike Frysinger
Quoted 10 lines · On Wednesday, August 31, 2011 11:11:00 Marek Vasut wrote:
Quoted 7 lines · Mike Frysinger
Quoted 2 lines · On Wednesday, August 31, 2011 06:38:50 Che-Liang Chiou wrote:

This patch adds a 64-64 bit divider that supports ARMv4 and above.

why ? if you're doing 64 bit divides, chances are you're doing something fundamentally wrong. perhaps you should fix that instead.

Oh come on Mike, what about too big NAND memories ?

Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

Linux hasnt had a problem supporting large NAND without a 64bit divide routine. why are we special ?

Because someone (?) has to fix the code that uses do_div() ;-)

sure ... the guy with the problem gets to post the fix :)

Cool, would that be ... you ? ;-)

no, because it's building fine for me, thus i dont have a problem
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110831/f22010ea/attachment.pgp

#9 lore raw

PATCH 1/1 arm: add 64-64 bit divider

In reply to Che-Liang Chiou

Dear Che-Liang Chiou,

Quoted 1 line · In message <[email protected]> you wrote:

This patch adds a 64-64 bit divider that supports ARMv4 and above.

To summarize the misc feedback: Please explain in detail which problem you are trying to fix. We see no need for this patch so far.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Success covers a multitude of blunders."       - George Bernard Shaw
author
#10 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Hi,

Thanks for the insightful comments. Here are my responses:

* Why don't I implement the divider in C?
It is not because I think it's performance critical (I haven't benchmarked it yet), but because I have a probably wrong impression that the divider has to be written in assembly --- all dividers in arch/arm/lib/ are written in ARM assembly. What is the policy here for using assembly or C?

* When do we need a 64-bit divider?
In kernel code do_div() is used for various purposes. So I think it should be quite often that we would need a 64-bit divider in U-Boot.

* Do we need a 64-64 bit divider?
do_div() defines 64-32 bit division semantics (dividend is 64-bit and divisor is 32-bit), and this patch implements a 64-64 bit divider (both dividend and divisor are 64-bit). I have to admit that I can't think of scenarios or reasons to justify a 64-64 bit divider instead of a 64-32 bit divider, except that a 64-64 bit divider is more generic than a 64-32 bit one.

So I guess we can agree that a 64-bit divider is feature that is nice to have, and we should decide:
* Do we need a 64-64 bit divider or a 64-32 bit one?
* Do we write it in C or assembly?

Depending on our decisions, I will rewrite (or abandon) this patch accordingly.

Regards,
Che-Liang

Quoted 18 lines · Wolfgang Denk

Dear Che-Liang Chiou,

Quoted 1 line · In message <[email protected]> you wrote:

This patch adds a 64-64 bit divider that supports ARMv4 and above.

To summarize the misc feedback: ?Please explain in detail which problem you are trying to fix. ?We see no need for this patch so far.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "Success covers a multitude of blunders." ? ? ? - George Bernard Shaw

#11 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Quoted 10 lines · Che-liang Chiou

Hi,

Thanks for the insightful comments. Here are my responses:

* Why don't I implement the divider in C?
It is not because I think it's performance critical (I haven't benchmarked it yet), but because I have a probably wrong impression that the divider has to be written in assembly --- all dividers in arch/arm/lib/ are written in ARM assembly. What is the policy here for using assembly or C?

No, C is just fine and is more generic. Those assembler versions are just optimized things, you don't need to be bothered by those.

Quoted 4 lines

* When do we need a 64-bit divider?
In kernel code do_div() is used for various purposes. So I think it should be quite often that we would need a 64-bit divider in U-Boot.

Not much really ... and for the rare cases, we can do with do_div() as is.

Quoted 8 lines

* Do we need a 64-64 bit divider?
do_div() defines 64-32 bit division semantics (dividend is 64-bit and divisor is 32-bit), and this patch implements a 64-64 bit divider (both dividend and divisor are 64-bit). I have to admit that I can't think of scenarios or reasons to justify a 64-64 bit divider instead of a 64-32 bit divider, except that a 64-64 bit divider is more generic than a 64-32 bit one.

So we don't need 64/64 divide at all.

Quoted 4 lines

So I guess we can agree that a 64-bit divider is feature that is nice to have, and we should decide:
* Do we need a 64-64 bit divider or a 64-32 bit one?

64-32 is do_div()

Quoted 1 line

* Do we write it in C or assembly?

C is OK.

Quoted 3 lines

Depending on our decisions, I will rewrite (or abandon) this patch accordingly.

Look, I don't mean to be rough, but honestly. I see no use for this code. Adding code to anywhere so it'd just sit there is bad.

Cheers

Quoted 8 lines

Regards,
Che-Liang

Quoted 3 lines · Wolfgang Denk

Dear Che-Liang Chiou,

In message <[email protected]> you

Quoted 14 lines · wrote:
Quoted 14 lines
Quoted 1 line

This patch adds a 64-64 bit divider that supports ARMv4 and above.

To summarize the misc feedback: Please explain in detail which problem you are trying to fix. We see no need for this patch so far.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Success covers a multitude of blunders." - George Bernard Shaw

author
#12 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Hi Marek,

I will abandon this patch and submit a new patch that is adapted from do_div() and lib64.c of the Linux kernel. Does this sound okay to you?

Regards,
Che-Liang

Quoted 77 lines · Marek Vasut
Quoted 10 lines · Che-liang Chiou

Hi,

Thanks for the insightful comments. Here are my responses:

* Why don't I implement the divider in C?
It is not because I think it's performance critical (I haven't benchmarked it yet), but because I have a probably wrong impression that the divider has to be written in assembly --- all dividers in arch/arm/lib/ are written in ARM assembly. What is the policy here for using assembly or C?

No, C is just fine and is more generic. Those assembler versions are just optimized things, you don't need to be bothered by those.

Quoted 4 lines

* When do we need a 64-bit divider?
In kernel code do_div() is used for various purposes. So I think it should be quite often that we would need a 64-bit divider in U-Boot.

Not much really ... and for the rare cases, we can do with do_div() as is.

Quoted 8 lines

* Do we need a 64-64 bit divider?
do_div() defines 64-32 bit division semantics (dividend is 64-bit and divisor is 32-bit), and this patch implements a 64-64 bit divider (both dividend and divisor are 64-bit). I have to admit that I can't think of scenarios or reasons to justify a 64-64 bit divider instead of a 64-32 bit divider, except that a 64-64 bit divider is more generic than a 64-32 bit one.

So we don't need 64/64 divide at all.

Quoted 4 lines

So I guess we can agree that a 64-bit divider is feature that is nice to have, and we should decide:
* Do we need a 64-64 bit divider or a 64-32 bit one?

64-32 is do_div()

Quoted 1 line

* Do we write it in C or assembly?

C is OK.

Quoted 3 lines

Depending on our decisions, I will rewrite (or abandon) this patch accordingly.

Look, I don't mean to be rough, but honestly. I see no use for this code. Adding code to anywhere so it'd just sit there is bad.

Cheers

Quoted 8 lines

Regards,
Che-Liang

Quoted 3 lines · Wolfgang Denk

Dear Che-Liang Chiou,

In message <[email protected]> you

Quoted 14 lines · wrote:
Quoted 14 lines
Quoted 1 line

This patch adds a 64-64 bit divider that supports ARMv4 and above.

To summarize the misc feedback: ?Please explain in detail which problem you are trying to fix. ?We see no need for this patch so far.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "Success covers a multitude of blunders." ? ? ? - George Bernard Shaw

#13 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Quoted 4 lines · Che-liang Chiou

Hi Marek,

I will abandon this patch and submit a new patch that is adapted from do_div() and lib64.c of the Linux kernel. Does this sound okay to you?

I'm not against it, but is it worth the effort? Like ... why do we need it ?

Quoted 3 lines

Regards,
Che-Liang

[...]

author
#14 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Hi Marek,

do_div() and lib/div64.c of linux kernel has been ported to U-Boot since Oct, 2006 (this date is the earliest record that I can find; see commit 7b64fef3).

Regards,
Che-Liang

Quoted 12 lines · Marek Vasut
Quoted 4 lines · Che-liang Chiou

Hi Marek,

I will abandon this patch and submit a new patch that is adapted from do_div() and lib64.c of the Linux kernel. Does this sound okay to you?

I'm not against it, but is it worth the effort? Like ... why do we need it ?

Quoted 3 lines

Regards,
Che-Liang

[...]

#15 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Dear Che-liang Chiou,

Quoted 4 lines · In message <CANJuy2K9uWdxT6T=mMj0yLiV3cAJUHLNC4LGDv21sP-DMGVzUg@mail.gmail.com>…

do_div() and lib/div64.c of linux kernel has been ported to U-Boot since Oct, 2006 (this date is the earliest record that I can find; see commit 7b64fef3).

Indeed, and so far nobody ever needed the patch you submitted, so please explain in detail why you need it now?

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"More software projects have gone awry for lack of calendar time than
for all other causes combined."
                         - Fred Brooks, Jr., _The Mythical Man Month_
author
#16 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Dear Wolfgang,

I am convinced that a 64-64 bit divider (this patch) is not needed. Is there any way that we could mark a patch "abandon"?

Regards,
Che-Liang

Quoted 23 lines · Wolfgang Denk

Dear Che-liang Chiou,

Quoted 4 lines · In message <CANJuy2K9uWdxT6T=mMj0yLiV3cAJUHLNC4LGDv21sP-DMGVzUg@mail.gmail.com>…

do_div() and lib/div64.c of linux kernel has been ported to U-Boot since Oct, 2006 (this date is the earliest record that I can find; see commit 7b64fef3).

Indeed, and so far nobody ever needed the patch you submitted, so please explain in detail why you need it now?

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "More software projects have gone awry for lack of calendar time than for all other causes combined."
? ? ? ? ? ? ? ? ? ? ? ? - Fred Brooks, Jr., _The Mythical Man Month_

#17 lore raw

PATCH 1/1 arm: add 64-64 bit divider

In reply to Che-liang Chiou

Dear Che-liang Chiou,

Quoted 5 lines · In message <CANJuy2+BB7tA70vHoTq3LJA-o4ymGCSdP9PnFzrx-uWret7nqQ@mail.gmail.com>…

So I guess we can agree that a 64-bit divider is feature that is nice to have, and we should decide:
* Do we need a 64-64 bit divider or a 64-32 bit one?
* Do we write it in C or assembly?

The situation is simple: there is no code in U-Boot that needs this feature, and we try to avoid adding dead code.

If you don;t have a use case at hand that actually requires this, then please let's drop it.

Thanks.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Real programmers don't comment their code. It was hard to  write,  it
should be hard to understand.
#18 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Hi Wolfgang,

Quoted 9 lines · Wolfgang Denk

Dear Che-liang Chiou,

Quoted 5 lines · In message <CANJuy2+BB7tA70vHoTq3LJA-o4ymGCSdP9PnFzrx-uWret7nqQ@mail.gmail.com>…

So I guess we can agree that a 64-bit divider is feature that is nice to have, and we should decide:
* Do we need a 64-64 bit divider or a 64-32 bit one?
* Do we write it in C or assembly?

Quoted 5 lines

The situation is simple: there is no code in U-Boot that needs this feature, and we try to avoid adding dead code.

If you don;t have a use case at hand that actually requires this, then please let's drop it.

You'll laugh at this - the Intel High Performance Event Timers (HPET) are defined to a resolution of femto-seconds and you end up with code in get_timer() like:

	u32 count_low;
	u32 count_high;
	u32 fs_per_tick;
	u64 ticks;
	u64 fs;
	u32 ms;

	count_low = readl(&hpet_registers->main_count_low);
	count_high = readl(&hpet_registers->main_count_high);
	fs_per_tick = readl(&hpet_registers->counter_clk_period);

	ticks = ((u64)count_high << 32) | ((u64)count_low);
	fs = fs_per_tick * ticks;
	ms = (u32)lldiv(ticks, 1000000000000);

But I can right shift both divisor and dividend by 12 bits without loosing any significant precision which turns it into:

	ms = (u32)lldiv(ticks >> 12, 244140625);

So I almost needed a 64 bit divisor.

Regards,

Graeme

#19 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Dear Graeme Russ,

Quoted 4 lines · In message <[email protected]> you wrote:

You'll laugh at this - the Intel High Performance Event Timers (HPET) are defined to a resolution of femto-seconds and you end up with code in get_timer() like:

I have to admit that I have never been able to laugh about x86 design issues. But then, Intel told us the Pentium would have "RISK" features...

Best regards,

Wolfgang Denk

Signature · 7 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When the tide of life turns against you
And the current upsets your boat
Don't waste tears on what might have been
Just lie on your back and float.
#20 lore raw

PATCH 1/1 arm: add 64-64 bit divider

Quoted 11 lines · Wolfgang Denk

Dear Graeme Russ,

Quoted 4 lines · In message <[email protected]> you wrote:

You'll laugh at this - the Intel High Performance Event Timers (HPET) are defined to a resolution of femto-seconds and you end up with code in get_timer() like:

I have to admit that I have never been able to laugh about x86 design issues. But then, Intel told us the Pentium would have "RISK" features...

*ROFL*

Well actually, it's not really an x86 thing - Any architecture could implement HPET. Using femto-seconds as the time-base and defining a 'tick' as a number of femto-seconds makes a lot of sense - It allows preservation of timer accuracy through the comparators so interrupts can be generated with extreme precision while actually allowing the source clock to be pretty much any frequency. They were, after all, designed for multi-media applications to solve the horrendous sub-ms accuracy issue with the older programmable timers

Regards,

Graeme