[9fans] arm compiler info

[9fans] arm compiler info

[Steve Simon]

Hi,

I'am just taking over a project at work which
uses an embedded ARM CPU. I'am told its an ARM 9 TDMI,
also known as an ARM 922. Anyone any idea if I could
cross compile using the Plan9 arm compiler? Is the
arm7 (the compiler) a subset of the arm9?

Also this project uses position independant code & data
and ELF files, doing a link/load on program startup. I could
code aout2elf quite easily but does

If the compiler is a non-starter then I may have a go at
bringing the arm7 GCC crosscompiler up on the back
of dhogs native GCC.

I know the better solution is to modify the arm9 compiler
but I am still up to my eyes in CIFS in my spare time so
I cannot waste work time on playing plan9 compilers (shame).

-Steve

Re: [9fans] arm compiler info

[Bruce Ellis]

it isn't hard to get ELF output, both vl and el have
a flag for it so changing 5l is a snarf/paste or too.
i'm not aware of the 922 arch but i think getting 5c/5l
to accomodate it is not too hard.  charles will have
something to say i'm sure.

brucee
[compiler writer seeking work]

Steve Simon wrote:

> Hi,
>
> I'am just taking over a project at work which
> uses an embedded ARM CPU. I'am told its an ARM 9 TDMI,
> also known as an ARM 922. Anyone any idea if I could
> cross compile using the Plan9 arm compiler? Is the
> arm7 (the compiler) a subset of the arm9?
>
> Also this project uses position independant code & data
> and ELF files, doing a link/load on program startup. I could
> code aout2elf quite easily but does
>
> If the compiler is a non-starter then I may have a go at
> bringing the arm7 GCC crosscompiler up on the back
> of dhogs native GCC.
>
> I know the better solution is to modify the arm9 compiler
> but I am still up to my eyes in CIFS in my spare time so
> I cannot waste work time on playing plan9 compilers (shame).
>
> -Steve

Re: [9fans] arm compiler info

[Steve Simon]

> [compiler writer seeking work]

If twer in my power to give work to professional
programmers to write code for plan9...

-Steve

Re: [9fans] arm compiler info

[boyd, rounin]

> If twer in my power to give work to professional
> programmers to write code for plan9...

tell me about it ...

[9fans] acme Zerox: Get lost

[Charles Forsyth]

i'd got the feeling once that a lost edit might
have been explained if Get hadn't worked on my Zerox'd file,
and took a moment just now to find that indeed Get
was ignored when applied to any frame of a file
with several Zerox'd views.

that's because in /sys/src/cmd/acme/exec.c:/^get\( if t->file->ntext>1 get
moans if the several-window thing is a directory, and then
returns.  but it always returns!  i suspect
the return should be attached to the moan.

Re: [9fans] acme Zerox: Get lost

[Rob Pike]

On Thu, 6 May 2004 11:05:52 +0100, Charles Forsyth
<forsyth@terzarima.net> wrote:
>
> i'd got the feeling once that a lost edit might
> have been explained if Get hadn't worked on my Zerox'd file,
> and took a moment just now to find that indeed Get
> was ignored when applied to any frame of a file
> with several Zerox'd views.
>
> that's because in /sys/src/cmd/acme/exec.c:/^get\( if t->file->ntext>1 get
> moans if the several-window thing is a directory, and then
> returns.  but it always returns!  i suspect
> the return should be attached to the moan.

absolutely. stupid bug. i know how it happened.

-rob

Re: [9fans] arm compiler info

[Charles Forsyth]

>>it isn't hard to get ELF output, both vl and el have
>>a flag for it so changing 5l is a snarf/paste or too.

or it would be if the elf weren't demented.
one of those scary ones.

5c/5l code will run on arm 9 (there are possibly some
extensions in arm 9, and if so, they won't use them,
though even that is usually easily dealt with).

possibly the bigger complication is the extent to
which the output is PIC enough (or can easily be
made so) for this application.  i remember looking
at an ARM application note about that but just
remember my resulting dismay, not what caused it.
it might not have been the PIC conventions as
such but its interaction with something else.

as to that ELF, is the loading program expecting
a completely linked program or something that
is then linked dynamically into one already running?
if the former, the existing ELF-header producing
code might well suffice (with the usual changes
to account for dementia, hence some of the "??"
in comments in existing code); if the latter, you'd need
to convert the symbols as well, and perhaps capture
and convert data for relocation (which isn't normally
produced except for dynamically-loaded modules).
i'm assuming you're safe from the elf's mate, a sly dwarf.

Re: [9fans] arm compiler info

[Steve Simon]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

some more detail:

Embedded APM system.

We have a kernel with a flash file system and serial console,
user programs (ls, cp, mv, The-big-app) are run from flash.

We don't program the MMU except to configure memory to be flat.

All user programs are relocated on load, under GCC the elf file contains
special global offset table sections which must be fixed-up, GreenHills
actually compiles code into crt0 to do this in every executable. Data is
referenced via a single register that contains the offset of the start of data.

User progs get access to kernel resources vla a jump table they are passed
on the stack when they start.

What I am really after is a nicer enviroment to work under than XP and
Greenhills (GCC helps but still ties me to MSDOS).

However my major concern is how much time I might spend getting this working,
if its a few days then no problem...

I guess I need to start looking at 5l, or understanding the MMU properly
so all programs can run at the same virtual address.

-Steve

[-- Attachment #2: Type: message/rfc822, Size: 3157 bytes --]

From: Charles Forsyth <forsyth@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] arm compiler info
Date: Thu, 6 May 2004 11:29:37 +0100
Message-ID: <59a028e5e416c7482661502ee195ddf5@terzarima.net>

>>it isn't hard to get ELF output, both vl and el have
>>a flag for it so changing 5l is a snarf/paste or too.

or it would be if the elf weren't demented.
one of those scary ones.

5c/5l code will run on arm 9 (there are possibly some
extensions in arm 9, and if so, they won't use them,
though even that is usually easily dealt with).

possibly the bigger complication is the extent to
which the output is PIC enough (or can easily be
made so) for this application.  i remember looking
at an ARM application note about that but just
remember my resulting dismay, not what caused it.
it might not have been the PIC conventions as
such but its interaction with something else.

as to that ELF, is the loading program expecting
a completely linked program or something that
is then linked dynamically into one already running?
if the former, the existing ELF-header producing
code might well suffice (with the usual changes
to account for dementia, hence some of the "??"
in comments in existing code); if the latter, you'd need
to convert the symbols as well, and perhaps capture
and convert data for relocation (which isn't normally
produced except for dynamically-loaded modules).
i'm assuming you're safe from the elf's mate, a sly dwarf.