Subject: RPM/Handling ARM /etc

From: Alan Cox <[email-masked]>
Date: Thu, 3 Sep 1998 01:52:37 +0100

Amazingly enough when I talk to both sides I get totally different stories.
So either someone is telling porkies, or as I much more suspect both sides
have their wires crossed.

Erik's comments being

<ewt> _A_: I asked if there was a pragma, said I liked that best, and *never
  got an answer*

So perhaps everyone can go back to civilised discussion of why __packed__
isnt suitable, and the best way to handle it.

Alan
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: "Andrew E. Mileski" <[email-masked]>
Date: Wed, 02 Sep 1998 23:41:06 -0400

> have their wires crossed.

They indeed have.  I've been blamed for Russell's comment!

> isnt suitable, and the best way to handle it.

Because it is compiler specific.

It is easy to re-write the code, and more portable too!
Each member of a structure should be read/written a byte
at a time.  I think the new tag based code does this
already for example.

--
Andrew E. Mileski
Software Developer
Corel Computer Corp.

---

From: phil <[email-masked]>
Date: Thu, 03 Sep 1998 08:55:27 +0100

In message <[email-masked]>

> at a time.  I think the new tag based code does this

I really do hope you're not advocating what I think you're advocating.  The
reading of structures byte-by-byte is extremely slow.  Consider the situation
where you have four bytes you wish to read from where r0 is pointing to, and
you wish to assemble a 32-bit int from these which will be placed in r1.

Optimal way:
     ldr     r1,[r0]

What you seem to be suggesting:
     ldrb    r1,[r0]
     ldrb    r14,[r0,#1]
     orr     r1,r1,r14,lsl #8
     ldrb    r14,[r0,#2]
     orr     r1,r1,r14,lsl #16
     ldrb    r14,[r0,#3]
     orr     r1,r1,r14,lsl #24

Please do tell me if I have misunderstood what you said, but you seem to be
advocating the use (for a situation which occurs very often indeed) of a
seven-fold increase in program size and a five-fold (at least) decrease in
performance.

Here's hoping I misread,
Phil

---

From: Philip Blundell <[email-masked]>
Date: Thu, 03 Sep 1998 09:33:43 +0100

>you wish to assemble a 32-bit int from these which will be placed in r1.

He's talking about file I/O, not general in-memory structures.

p.

---

From: Erik Troan <[email-masked]>
Date: Thu, 3 Sep 1998 11:17:55 -0400 (EDT)

> Because it is compiler specific.

What other compilers/OSs are there for the ARM which makes this an actual
problem?

> at a time.  I think the new tag based code does this

I'l like to see a clean patch; nobody has bothred submitting one. Ideally,
it would define a cpio_read_header(), which:

	1) does a single read() into the structure on archs which pack
	   the cpio header "correctly" ("correctly" being defined as "in
	   the same way as the cpio format needs", not "correct" as in
	   "Erik's way"); configure can easily be modified to check for
	   this
	2) does a single read() into a buffer on other archs, and then
	   copies the bits into the structure after the read

Erik

-------------------------------------------------------------------------------
|       "For the next two hours, VH1 will be filled with foul-mouthed,        |
|          crossdressing Australians. Viewer discretion is advised."          |
|                                                                             |
|   Linux Application Development  --  http://www.redhat.com/~johnsonm/lad    |

---

From: "Andrew E. Mileski" <[email-masked]>
Date: Thu, 03 Sep 1998 11:58:56 -0400

> What other compilers/OSs are there for the ARM which makes this an actual

I wasn't thinking of the ARM, I'm thinking of a generic
all-processor compatible fix.

> I'l like to see a clean patch; nobody has bothred submitting one. 
I know.  That's why I never submitted by ARM "hacks".
A completely portable fix is better (and possible).