* [9fans] arm compiler info @ 2004-05-05 10:45 Steve Simon 2004-05-05 13:51 ` Bruce Ellis 0 siblings, 1 reply; 8+ messages in thread From: Steve Simon @ 2004-05-05 10:45 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] arm compiler info 2004-05-05 10:45 [9fans] arm compiler info Steve Simon @ 2004-05-05 13:51 ` Bruce Ellis 2004-05-05 14:04 ` Steve Simon ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Bruce Ellis @ 2004-05-05 13:51 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] arm compiler info 2004-05-05 13:51 ` Bruce Ellis @ 2004-05-05 14:04 ` Steve Simon 2004-05-05 19:25 ` boyd, rounin 2004-05-06 10:05 ` [9fans] acme Zerox: Get lost Charles Forsyth 2004-05-06 10:29 ` [9fans] arm compiler info Charles Forsyth 2 siblings, 1 reply; 8+ messages in thread From: Steve Simon @ 2004-05-05 14:04 UTC (permalink / raw) To: 9fans > [compiler writer seeking work] If twer in my power to give work to professional programmers to write code for plan9... -Steve ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] arm compiler info 2004-05-05 14:04 ` Steve Simon @ 2004-05-05 19:25 ` boyd, rounin 0 siblings, 0 replies; 8+ messages in thread From: boyd, rounin @ 2004-05-05 19:25 UTC (permalink / raw) To: 9fans > If twer in my power to give work to professional > programmers to write code for plan9... tell me about it ... ^ permalink raw reply [flat|nested] 8+ messages in thread
* [9fans] acme Zerox: Get lost 2004-05-05 13:51 ` Bruce Ellis 2004-05-05 14:04 ` Steve Simon @ 2004-05-06 10:05 ` Charles Forsyth 2004-05-07 0:02 ` Rob Pike 2004-05-06 10:29 ` [9fans] arm compiler info Charles Forsyth 2 siblings, 1 reply; 8+ messages in thread From: Charles Forsyth @ 2004-05-06 10:05 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] acme Zerox: Get lost 2004-05-06 10:05 ` [9fans] acme Zerox: Get lost Charles Forsyth @ 2004-05-07 0:02 ` Rob Pike 0 siblings, 0 replies; 8+ messages in thread From: Rob Pike @ 2004-05-07 0:02 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] arm compiler info 2004-05-05 13:51 ` Bruce Ellis 2004-05-05 14:04 ` Steve Simon 2004-05-06 10:05 ` [9fans] acme Zerox: Get lost Charles Forsyth @ 2004-05-06 10:29 ` Charles Forsyth 2004-05-06 12:24 ` Steve Simon 2 siblings, 1 reply; 8+ messages in thread From: Charles Forsyth @ 2004-05-06 10:29 UTC (permalink / raw) To: 9fans >>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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] arm compiler info 2004-05-06 10:29 ` [9fans] arm compiler info Charles Forsyth @ 2004-05-06 12:24 ` Steve Simon 0 siblings, 0 replies; 8+ messages in thread From: Steve Simon @ 2004-05-06 12:24 UTC (permalink / raw) To: 9fans [-- 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2004-05-07 0:02 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-05-05 10:45 [9fans] arm compiler info Steve Simon 2004-05-05 13:51 ` Bruce Ellis 2004-05-05 14:04 ` Steve Simon 2004-05-05 19:25 ` boyd, rounin 2004-05-06 10:05 ` [9fans] acme Zerox: Get lost Charles Forsyth 2004-05-07 0:02 ` Rob Pike 2004-05-06 10:29 ` [9fans] arm compiler info Charles Forsyth 2004-05-06 12:24 ` Steve Simon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).