1. ARM and Position Independent Code
- Posted by mattlewis (admin) Mar 04, 2013
- 2696 views
Can anyone confirm or deny whether ARM requires Position Independent Code (PIC) for building shared libraries? x86-64 on Linux does, but none of the other platforms that we support do. This required an additional runtime library for translating x86-64 shared libraries.
I'd like to get rid of this for platforms that don't need it, but I don't have access to any ARM stuff.
Matt
2. Re: ARM and Position Independent Code
- Posted by rkdavis Mar 04, 2013
- 2640 views
i believe it does at least all the 3rd party libs (.so) i've built have -fPIC in their makefile.
3. Re: ARM and Position Independent Code
- Posted by rkdavis Mar 04, 2013
- 2629 views
actually this is really going to be a helpful reply :)
ust asked a guy who has written an ARM shared lib and he says he doesn't think so :)
so the defintive answer is
yes & no
4. Re: ARM and Position Independent Code
- Posted by rkdavis Mar 04, 2013
- 2651 views
the arm docs seem to indicate it is
The linker outputs a downgradable error if --shared is used and --fpic is not used.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0493c/CHDECFHF.html
5. Re: ARM and Position Independent Code
- Posted by jimcbrown (admin) Mar 04, 2013
- 2605 views
actually this is really going to be a helpful reply :)
ust asked a guy who has written an ARM shared lib and he says he doesn't think so :)
so the defintive answer is
yes & no
I wouldn't be suprised if, for example, the answer was different on ARMv5 and ARMv6.
6. Re: ARM and Position Independent Code
- Posted by Jerome Mar 04, 2013
- 2615 views
I wouldn't be suprised if, for example, the answer was different on ARMv5 and ARMv6.
I can confirm tonight after work; I have an ARMv6 and ARMv7.
Thanks,
Ira
7. Re: ARM and Position Independent Code
- Posted by EUWX Mar 04, 2013
- 2569 views
Can anyone confirm or deny whether ARM requires Position Independent Code (PIC) for building shared libraries? x86-64 on Linux does, but none of the other platforms that we support do. This required an additional runtime library for translating x86-64 shared libraries.
I'd like to get rid of this for platforms that don't need it, but I don't have access to any ARM stuff.
Matt
.so files by their very nature have Position Independent Code. You might consider using .so use temporarily during the development. Some languages like QB64 for windows platform use several .dll files and never a final .exe till the user writes his own code and compiles it.
8. Re: ARM and Position Independent Code
- Posted by jimcbrown (admin) Mar 04, 2013
- 2573 views
Can anyone confirm or deny whether ARM requires Position Independent Code (PIC) for building shared libraries? x86-64 on Linux does, but none of the other platforms that we support do. This required an additional runtime library for translating x86-64 shared libraries.
I'd like to get rid of this for platforms that don't need it, but I don't have access to any ARM stuff.
Matt
.so files by their very nature have Position Independent Code.
It is possible to compile and build a .so file (ELF, on x86 32bit) without -fPIC. The ELF loader (ld-linux.so.2) may have to go through some extra trouble to load the resulting shared object, however.
9. Re: ARM and Position Independent Code
- Posted by Jerome Mar 04, 2013
- 2576 views
Can anyone confirm or deny whether ARM requires Position Independent Code (PIC) for building shared libraries? x86-64 on Linux does, but none of the other platforms that we support do. This required an additional runtime library for translating x86-64 shared libraries.
My original plan was to recompile libraries I often use on my ARM devices but without -fPIC. I did this for the Pi (Armv6) using wiringPi and on my Nokia (Armv7) with wxEuphoria. Both shared libraries still work as expected. After reading this http://stackoverflow.com/questions/5311515/gcc-fpic-option, I might be oversimplifying things though. I guess there could still be instances where not using -fPIC might cause problems. Is there something in particular I can test?
Thanks,
Ira
10. Re: ARM and Position Independent Code
- Posted by jimcbrown (admin) Mar 05, 2013
- 2541 views
My original plan was to recompile libraries I often use on my ARM devices but without -fPIC. I did this for the Pi (Armv6) using wiringPi and on my Nokia (Armv7) with wxEuphoria. Both shared libraries still work as expected. After reading this http://stackoverflow.com/questions/5311515/gcc-fpic-option, I might be oversimplifying things though. I guess there could still be instances where not using -fPIC might cause problems. Is there something in particular I can test?
Thanks,
Ira
I guess that depends on how you define "cause problems." :)
Yes, they will still work, but they may take longer to load, and you may require multiple copies of the same library to be loaded in memory.
http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/
Can anyone confirm or deny whether ARM requires Position Independent Code (PIC) for building shared libraries? x86-64 on Linux does,
Bonus: There is an exception to the x86-64 rule (where non-PIC shared objects are allowed).
11. Re: ARM and Position Independent Code
- Posted by jimcbrown (admin) Mar 05, 2013
- 2472 views
I'd like to get rid of this for platforms that don't need it
Why? To eliminate the need for the extra shared object?
12. Re: ARM and Position Independent Code
- Posted by mattlewis (admin) Mar 05, 2013
- 2483 views
I'd like to get rid of this for platforms that don't need it
Why? To eliminate the need for the extra shared object?
The extra runtime libraries. Up to 4.0, we only ever shipped the one, and it was not built with -fPIC, and the build process for a translated shared object never used it, either. I found that it was required for x86-64, so I added the euso.a runtime library (and its debug version, eusodbg.a).
It's definitely not needed for Windows, and doesn't seem to be needed for x86 Linux (and no one else ever complained about it, though I haven't tested any BSDs).
Matt
13. Re: ARM and Position Independent Code
- Posted by jimcbrown (admin) Mar 05, 2013
- 2503 views
I'd like to get rid of this for platforms that don't need it
Why? To eliminate the need for the extra shared object?
The extra runtime libraries. Up to 4.0, we only ever shipped the one, and it was not built with -fPIC, and the build process for a translated shared object never used it, either. I found that it was required for x86-64, so I added the euso.a runtime library (and its debug version, eusodbg.a).
It's definitely not needed for Windows, and doesn't seem to be needed for x86 Linux (and no one else ever complained about it, though I haven't tested any BSDs).
Matt
Thinking it over, we might want to keep it as an optional feature. We don't really target embedded systems yet, but using fPIC on the right platform can save us both memory and speed. (I've read that, unlike x86, fPIC actually results in faster code on ARM.)
The benefits of fPIC show up best if we have thousands of processes loading and unloading the same several thousand shared objects. These scenarios are probably rare, but (as long as its optional), why not?
14. Re: ARM and Position Independent Code
- Posted by useless_ Mar 05, 2013
- 2445 views
I think it's a joke that what's essentially a 800Mhz C-64 (with an vastly improved 6502) on a single chip is instead a mental puzzle that's wasting millions of hours of people trying to get *nix and various guis and the most complicated of programming languages installed on it.
useless
15. Re: ARM and Position Independent Code
- Posted by mattlewis (admin) Mar 05, 2013
- 2456 views
I think it's a joke that what's essentially a 800Mhz C-64 (with an vastly improved 6502) on a single chip is instead a mental puzzle that's wasting millions of hours of people trying to get *nix and various guis and the most complicated of programming languages installed on it.
Two ARMs and a Xeon walk into a bar...
Matt
16. Re: ARM and Position Independent Code
- Posted by useless_ Mar 05, 2013
- 2444 views
I think it's a joke that what's essentially a 800Mhz C-64 (with an vastly improved 6502) on a single chip is instead a mental puzzle that's wasting millions of hours of people trying to get *nix and various guis and the most complicated of programming languages installed on it.
Two ARMs and a Xeon walk into a bar...
Matt
But seriously, why not a 100Kbyte bios to talk to the hardware in a minimal way, and to set up defaults and POST sequences, and then put Eu v3 on it behind an olde dos-looking prompt? Build up from there. Everyone trying to force 100's megabytes of different *nix kernals onto it, and the obvious difficulty they are having, is soooo not user-friendly. And they'll repeat it with each weekly re-compile *nix users do. Does no one remember when bios and boot code was 1K bytes? or 16K bytes? or even fit on a 1.44kbyte floppy? or when it worked when you applied power?
useless
17. Re: ARM and Position Independent Code
- Posted by jimcbrown (admin) Mar 05, 2013
- 2424 views
But seriously, why not a 100Kbyte bios to talk to the hardware in a minimal way, and to set up defaults and POST sequences, and then put Eu v3 on it behind an olde dos-looking prompt? Build up from there. Everyone trying to force 100's megabytes of different *nix kernals onto it, and the obvious difficulty they are having, is soooo not user-friendly. And they'll repeat it with each weekly re-compile *nix users do. Does no one remember when bios and boot code was 1K bytes? or 16K bytes? or even fit on a 1.44kbyte floppy? or when it worked when you applied power?
FreeDOS only works on x86 cpus, so that's simply not possible until someone does a port or makes a clone. (It's possible to emulate it, of course, but that's an obvious non-starter.)
(Even today, most kernels do not approach the 100-megabyte range...)
18. Re: ARM and Position Independent Code
- Posted by jimcbrown (admin) Mar 05, 2013
- 2418 views
(Even today, most kernels do not approach the 100-megabyte range...)
I take that back. An individual kernel probably wouldn't, but a bleeding edge alpha tester could probably go through several hundred distros (with assorted kernels, totalling in the hundreds of megas or possibly even in the giga range) in a couple of days.
19. Re: ARM and Position Independent Code
- Posted by EUWX Mar 05, 2013
- 2419 views
I think it's a joke that what's essentially a 800Mhz C-64 (with an vastly improved 6502) on a single chip is instead a mental puzzle that's wasting millions of hours of people trying to get *nix and various guis and the most complicated of programming languages installed on it.
Two ARMs and a Xeon walk into a bar...
Matt
But seriously, why not a 100Kbyte bios to talk to the hardware in a minimal way, and to set up defaults and POST sequences, and then put Eu v3 on it behind an olde dos-looking prompt? Build up from there. Everyone trying to force 100's megabytes of different *nix kernals onto it, and the obvious difficulty they are having, is soooo not user-friendly. And they'll repeat it with each weekly re-compile *nix users do. Does no one remember when bios and boot code was 1K bytes? or 16K bytes? or even fit on a 1.44kbyte floppy? or when it worked when you applied power?
useless
Once upon a time there was x86 processor, needing help for video. So developers (e.g. Nokia) created a separate video processor taking the UNREASONABLE load off the x86 processor. Then one day some smart guys discovered that the video processor was actually more powerful than the x86 processor and its mate the Arithmatic processor unit, and they actually went about developing software to work on the video processor - Have you heard of CUDA?
Then came the phone and tablet revolution and the smart guys modified the essentials of a video processor to create the enormously powerful ARM processor, extremely strong on video, all AV, etc. And grandfather Google gave Adroid OS to it too.
Now people are again discovering the power of the Arm processors and are trying to get a proper Linux on it, and Granddad Linus has given Kernel version 3.7 so there would be less problem getting Linux onto these ENORMOUSLY POWERFUL ARM PROCESSORS, shaking the very foundations of Microsoft.
Where does the useless C-64 and olde-dos come into the picture? The users of Arm processor on the various phones and tablets have never heard of the Olde dos or the new dos or the modern Dos and shrink away from the console mode of Linux. They only want graphic interface. so let us get this useless talk out of this thread and put it into a cage called "commodore 64" and BURY it, and then proceed with the Linux version of Euphoria as powerful or more powerful than the x86 version of Euphoria with the enormous graphics power harnessed to a great user experience.
20. Re: ARM and Position Independent Code
- Posted by EUWX Mar 05, 2013
- 2408 views
(I've read that, unlike x86, fPIC actually results in faster code on ARM.)
The benefits of fPIC show up best if we have thousands of processes loading and unloading the same several thousand shared objects. These scenarios are probably rare, but (as long as its optional), why not?
Any time a properly done "Position Independent Code" will always be speedier than Position dependent code, in any large project. Forget "several thousand shared objects" - even 30-40 shared objects would make fPIC a viable and desirable method.
21. Re: ARM and Position Independent Code
- Posted by jaygade Mar 05, 2013
- 2417 views
Umm, you know that ARM has been around since the 1980s, right?
Although I wouldn't compare it to a C64 either, since it's a 32-bit processor.
While I don't have one, I've never heard of people having problems running Linux on ARM or Raspberry Pi. Of course, ARM itself encompasses an entire series of CPUs and MCUs in a large number of configurations.
22. Re: ARM and Position Independent Code
- Posted by ghaberek (admin) Mar 05, 2013
- 2448 views
But seriously, why not a 100Kbyte bios to talk to the hardware in a minimal way, and to set up defaults and POST sequences, and then put Eu v3 on it behind an olde dos-looking prompt? Build up from there.
This sounds like a job for MINIX or Genode. Someone should get started on this.
Everyone trying to force 100's megabytes of different *nix kernals onto it, and the obvious difficulty they are having, is soooo not user-friendly. And they'll repeat it with each weekly re-compile *nix users do. Does no one remember when bios and boot code was 1K bytes? or 16K bytes? or even fit on a 1.44kbyte floppy? or when it worked when you applied power?
Unfortunately, silly concerns like security, stability, portability, expandability, and all sorts of other 'ilities start getting in the way and drive up the size of the kernel and/or its dependencies.
-Greg
23. Re: ARM and Position Independent Code
- Posted by useless_ Mar 05, 2013
- 2393 views
Some stuff about ARM and graphics.
The chip on the Pi is a graphics processor and an ARM on one chip.
and then proceed with the Linux version of Euphoria as powerful or more powerful than the x86 version of Euphoria with the enormous graphics power harnessed to a great user experience.
Sounds very anti-windoze to me.
useless
24. Re: ARM and Position Independent Code
- Posted by useless_ Mar 05, 2013
- 2381 views
Umm, you know that ARM has been around since the 1980s, right?
Although I wouldn't compare it to a C64 either, since it's a 32-bit processor.
I did say something like "a vastly improved 6502", not that 32bits means improved, but it does allow a bigger address space and faster big number crunching. AFAIK, the ARM was developed as direct competion to the olde 6500 series (which is still being made).
While I don't have one, I've never heard of people having problems running Linux on ARM or Raspberry Pi. Of course, ARM itself encompasses an entire series of CPUs and MCUs in a large number of configurations.
Umm, you know that Euphoria, in total, won't run on the Pi, right? There's a number of tickets just this week against Eu on linux-32 and the Pi, and some peoples have been working on getting Eu onto the pi for weeks.
useless
25. Re: ARM and Position Independent Code
- Posted by jaygade Mar 05, 2013
- 2353 views
- Last edited Mar 06, 2013
Umm, you know that ARM has been around since the 1980s, right?
Although I wouldn't compare it to a C64 either, since it's a 32-bit processor.
I did say something like "a vastly improved 6502", not that 32bits means improved, but it does allow a bigger address space and faster big number crunching. AFAIK, the ARM was developed as direct competion to the olde 6500 series (which is still being made).
Well, that means "improved" to me. I mean, I guess you could call a Ferrari a "vastly improved" Model T if you wanted to. Heck, you could even call a Prius or a Smart Car a "vastly improved" Model T and still be just as relevant.
While I don't have one, I've never heard of people having problems running Linux on ARM or Raspberry Pi. Of course, ARM itself encompasses an entire series of CPUs and MCUs in a large number of configurations.
Umm, you know that Euphoria, in total, won't run on the Pi, right? There's a number of tickets just this week against Eu on linux-32 and the Pi, and some peoples have been working on getting Eu onto the pi for weeks.
useless
Yeah, I'm aware that some people have had some success in getting Euphoria to run on the Raspberry Pi and other ARM systems, but that there are still some bugs to work out.
What does that have to do with my statement about running Linux on these devices?
26. Re: ARM and Position Independent Code
- Posted by useless_ Mar 06, 2013
- 2346 views
Umm, you know that ARM has been around since the 1980s, right?
Although I wouldn't compare it to a C64 either, since it's a 32-bit processor.
I did say something like "a vastly improved 6502", not that 32bits means improved, but it does allow a bigger address space and faster big number crunching. AFAIK, the ARM was developed as direct competion to the olde 6500 series (which is still being made).
Well, that means "improved" to me. I mean, I guess you could call a Ferrari a "vastly improved" Model T if you wanted to. Heck, you could even call a Prius or a Smart Car a "vastly improved" Model T and still be just as relevant.
While I don't have one, I've never heard of people having problems running Linux on ARM or Raspberry Pi. Of course, ARM itself encompasses an entire series of CPUs and MCUs in a large number of configurations.
Umm, you know that Euphoria, in total, won't run on the Pi, right? There's a number of tickets just this week against Eu on linux-32 and the Pi, and some peoples have been working on getting Eu onto the pi for weeks.
useless
Yeah, I'm aware that some people have had some success in getting Euphoria to run on the Raspberry Pi and other ARM systems, but that there are still some bugs to work out.
What does that have to do with my statement about running Linux on these devices?
Only that there are certain "recommended" versions of *nix to run on the Pi. *nix isn't the cure-all for running anything on anything.
useless
27. Re: ARM and Position Independent Code
- Posted by jaygade Mar 06, 2013
- 2360 views
Unlike Euphoria or the Pi is to this conversation, in which it seems you only want to define "vastly improved" and "relevant".
Okay. As usual, I have no idea what you mean here.
Yeah, I'm aware that some people have had some success in getting Euphoria to run on the Raspberry Pi and other ARM systems, but that there are still some bugs to work out.
What does that have to do with my statement about running Linux on these devices?
Only that there are certain "recommended" versions of *nix to run on the Pi, and Eu isn't running on the the Pi. *nix isn't the cure-all for running anything on anything.
Umm, actually I think that it kinda is. Which is why it has been around for forty plus years.
There are certain "recommended" versions of *nix to run on almost *any* device. Not just the Pi.
Are you going to nitpick and start slinging urls at me like some other nitpicker does on Euphorum? Maybe you can start a war based on me calling this "Euphorum". Or using quotes. Or putting the period at the end of the sentence instead of inside the last set of quotes. Whatever, i am sure it won't make the thread "vastly improved" or "relevant".
useless
Sure, if you want. I'm very good at nitpicking and slinging urls and quoting. Calling this "Euphorum" is just stupid, however.
28. Re: ARM and Position Independent Code
- Posted by mattlewis (admin) Mar 06, 2013
- 2354 views
I think the gist is that we should probably only remove this for Windows. Even though it doesn't seem strictly required on x86 Linux (and some ARM), we should be using it where appropriate.
Thanks for all the input.
Matt
29. Re: ARM and Position Independent Code
- Posted by jimcbrown (admin) Mar 06, 2013
- 2362 views
Umm, you know that Euphoria, in total, won't run on the Pi, right? There's a number of tickets just this week against Eu on linux-32 and the Pi, and some peoples have been working on getting Eu onto the pi for weeks.
I'd like to rephrase that as follows:
Euphoria, by and large, runs on the Pi, although there have been a number of loose ends to clean up, which people have spent a lot of time on.
30. Re: ARM and Position Independent Code
- Posted by mattlewis (admin) Mar 06, 2013
- 2318 views
Umm, you know that Euphoria, in total, won't run on the Pi, right? There's a number of tickets just this week against Eu on linux-32 and the Pi, and some peoples have been working on getting Eu onto the pi for weeks.
I'd like to rephrase that as follows:
Euphoria, by and large, runs on the Pi, although there have been a number of loose ends to clean up, which people have spent a lot of time on.
I would add that some of that work has been on ARM platforms other than the Pi. And porting to ARM has been a lot easier than porting to x86-64.
Matt
31. Re: ARM and Position Independent Code
- Posted by useless_ Mar 06, 2013
- 2288 views
Umm, you know that Euphoria, in total, won't run on the Pi, right? There's a number of tickets just this week against Eu on linux-32 and the Pi, and some peoples have been working on getting Eu onto the pi for weeks.
I'd like to rephrase that as follows:
Euphoria, by and large, runs on the Pi, although there have been a number of loose ends to clean up, which people have spent a lot of time on.
That IS what i said, no?
useless
32. Re: ARM and Position Independent Code
- Posted by useless_ Mar 06, 2013
- 2282 views
Umm, you know that Euphoria, in total, won't run on the Pi, right? There's a number of tickets just this week against Eu on linux-32 and the Pi, and some peoples have been working on getting Eu onto the pi for weeks.
I'd like to rephrase that as follows:
Euphoria, by and large, runs on the Pi, although there have been a number of loose ends to clean up, which people have spent a lot of time on.
I would add that some of that work has been on ARM platforms other than the Pi. And porting to ARM has been a lot easier than porting to x86-64.
Matt
I understand. And thanks. But some people have been pushing *nix and slamming windows, in what might be considered an attempt to get Eu off windows platforms entirely, or at least divert all dev resources to only *nix ports. I have also suggested Eu be ported to the smaller processor base (ARM, AVR, Propellor, etc), i just don't see my words as saying "only if *nix is also running on the platform", or "only if it's a 32bit cpu", or "only if it is in the most expensive devices". I am happy to see Eu expanding, and improving, but unlike some posts in this thread, i am not vehemently pushing my favorite *nix-only device above all others. Seriously, i get slammed for even mentioning another cpu??
useless
33. Re: ARM and Position Independent Code
- Posted by jimcbrown (admin) Mar 06, 2013
- 2238 views
Umm, you know that Euphoria, in total, won't run on the Pi, right? There's a number of tickets just this week against Eu on linux-32 and the Pi, and some peoples have been working on getting Eu onto the pi for weeks.
I'd like to rephrase that as follows:
Euphoria, by and large, runs on the Pi, although there have been a number of loose ends to clean up, which people have spent a lot of time on.
That IS what i said, no?
I believe so, yes. I'm worried that some simpleton might misread your original wording as "Eu isn't running on the the Pi", however, and thought the clarification might help.
34. Re: ARM and Position Independent Code
- Posted by jaygade Mar 06, 2013
- 2300 views
I'd like to rephrase that as follows:
Euphoria, by and large, runs on the Pi, although there have been a number of loose ends to clean up, which people have spent a lot of time on.
That IS what i said, no?
I believe so, yes. I'm worried that some simpleton might misread your original wording as "Eu isn't running on the the Pi", however, and thought the clarification might help.
I'm the simpleton in question, because that's how I understood the statement. Mea culpa, I guess.
My main point for even responding to this thread was EUWX's ridiculous claims, not to start a fight with useless. I just found that the specific comparison of the Raspberry Pi to a "800MHz C64" to be a silly comparison. Or at least as relevant as comparing to to a "800MHz <insert any type of computer here>".
Hah, I guess that I should know better by now though.
35. Re: ARM and Position Independent Code
- Posted by mattlewis (admin) Mar 06, 2013
- 2309 views
I understand. And thanks. But some people have been pushing *nix and slamming windows, in what might be considered an attempt to get Eu off windows platforms entirely, or at least divert all dev resources to only *nix ports.
I don't see that happening. Most of my time is spent on Linux, but I still do Windows stuff. And I know that most people run euphoria on Windows.
I have also suggested Eu be ported to the smaller processor base (ARM, AVR, Propellor, etc), i just don't see my words as saying "only if *nix is also running on the platform", or "only if it's a 32bit cpu", or "only if it is in the most expensive devices". I am happy to see Eu expanding, and improving, but unlike some posts in this thread, i am not vehemently pushing my favorite *nix-only device above all others. Seriously, i get slammed for even mentioning another cpu??
There's always someone around who will have a beef with something that anyone says. Especially if you lead with attacks on something else. I don't think anyone is against additional ports, but that's a lot harder if the target doesn't include an OS that we already support or that is at least very similar to one that we do.
Matt
36. OT: ARM and Position Independent Code
- Posted by jimcbrown (admin) Mar 06, 2013
- 2304 views
I'm the simpleton in question
You'll never be a simpleton to me.
37. Re: ARM and Position Independent Code
- Posted by useless_ Mar 06, 2013
- 2287 views
I have also suggested Eu be ported to the smaller processor base (ARM, AVR, Propellor, etc), i just don't see my words as saying "only if *nix is also running on the platform", or "only if it's a 32bit cpu", or "only if it is in the most expensive devices". I am happy to see Eu expanding, and improving, but unlike some posts in this thread, i am not vehemently pushing my favorite *nix-only device above all others. Seriously, i get slammed for even mentioning another cpu??
There's always someone around who will have a beef with something that anyone says. Especially if you lead with attacks on something else. I don't think anyone is against additional ports, but that's a lot harder if the target doesn't include an OS that we already support or that is at least very similar to one that we do.
Matt
It wasn't an attack on the Pi to say the ARM was a vastly improved 6502. [edit]Neither is it a slam to say the Broadcom video chip with the ARM in it is a 700Mhz C64, as it incorporates almost all the features of the C64 in the one chip. If i wanted to slam the Pi, i could make a list.[/edit]
The ARM1 was developed with the intention to use the 6502 design philosopy, and a visit to Western Design Center, the IP holder, and is still home to Bill Mensch, one of the original designers and promoters of the 6502, and someone i have emailed with a bit. The ARM team (before there was an ARM) had been using 6502 in their systems for years, and had considered a 16bit cpu, found all had issues, etc etc etc, and after visiting WDC went home and designed the ARM1 on a 6502 system. And like i have suggested for Eu before, they coded the BASIC interpreter for the ARM1 and a kernal as a package, much like the C64 (it has bios/kernal and Basic) and later the IBM PC, was done. But the ARM was most definitely as much an outgrowth and upgrade of the 6502 as the 6502 was a clone of the 6800, but without the lawsuits. The ARM1 was designed by 6502 KISS principles, and was simply wider and had more registers. I consider the low end AVR to be clones of the early ARMs. This stuff is online, people.
useless
38. Re: ARM and Position Independent Code
- Posted by mattlewis (admin) Mar 06, 2013
- 2292 views
I have also suggested Eu be ported to the smaller processor base (ARM, AVR, Propellor, etc), i just don't see my words as saying "only if *nix is also running on the platform", or "only if it's a 32bit cpu", or "only if it is in the most expensive devices". I am happy to see Eu expanding, and improving, but unlike some posts in this thread, i am not vehemently pushing my favorite *nix-only device above all others. Seriously, i get slammed for even mentioning another cpu??
There's always someone around who will have a beef with something that anyone says. Especially if you lead with attacks on something else. I don't think anyone is against additional ports, but that's a lot harder if the target doesn't include an OS that we already support or that is at least very similar to one that we do.
It wasn't an attack on the Pi to say the ARM was a vastly improved 6502. [edit]Neither is it a slam to say the Broadcom video chip with the ARM in it is a 700Mhz C64, as it incorporates almost all the features of the C64 in the one chip. If i wanted to slam the Pi, i could make a list.[/edit]
I was thinking more along the lines of, "I think it's a joke...wasting millions of hours ..."
Matt
39. Re: ARM and Position Independent Code
- Posted by useless_ Mar 06, 2013
- 2276 views
I have also suggested Eu be ported to the smaller processor base (ARM, AVR, Propellor, etc), i just don't see my words as saying "only if *nix is also running on the platform", or "only if it's a 32bit cpu", or "only if it is in the most expensive devices". I am happy to see Eu expanding, and improving, but unlike some posts in this thread, i am not vehemently pushing my favorite *nix-only device above all others. Seriously, i get slammed for even mentioning another cpu??
There's always someone around who will have a beef with something that anyone says. Especially if you lead with attacks on something else. I don't think anyone is against additional ports, but that's a lot harder if the target doesn't include an OS that we already support or that is at least very similar to one that we do.
It wasn't an attack on the Pi to say the ARM was a vastly improved 6502. [edit]Neither is it a slam to say the Broadcom video chip with the ARM in it is a 700Mhz C64, as it incorporates almost all the features of the C64 in the one chip. If i wanted to slam the Pi, i could make a list.[/edit]
I was thinking more along the lines of, "I think it's a joke...wasting millions of hours ..."
Matt
Ah. Ok. Let me clarify, maybe. . .
I was going back to the development of the Pi, when it was two chips, an ARM (any ARM, pick an ARM, maybe a new one?) and a video chip. Back then one had full access to the ARM and to the video processing, this isn't so with the current Pi (have you read the data sheet on that chip?). It was possible to add more external memory, after a fashion, now it isn't. To me, it's like looking at the existing Pi (vs the original Pi) and the C64 (vs the VIC20) and asking myself why they shot themselves in the foot while doing the upgrade. Anyhow, all that work was thrown out. Pi v2 was initially programmed with Fedora, then Debian was backtracked from ARM7 to ARM6 to make Raspbian, and other *nixes were also modified to various results. There's likely an army of people working alone or small groups to make the Pi useable on the version of *nix they prefer, that won't be able to run this, that, or the other thing from one Pi to the next. AFAIK, only Raspbian uses the Broadcom chip's floating point math hardware.
While designing software to a specific piece of hardware is easier (in my experience) than designing software for multiple OSs on various hardware (like Euphoria is), there was still 1000's of man-hours put into just backtracking Debian to be Raspbian, and that alone is more than all the effort put into the ARM1, near as i can tell, and that is not including the work to bring about Debian or Fedora in the first place! It's just an astonishing amount of work, when compared to the same goal of making an entry level computer 30 years ago.
It's highly unlikely Broadcom will put a ARM8 or 9 into the same package the Pi uses now, and they are so closely coupled to suit Broadcom's needs that even if Pi gets a free license to make a new chip with new ARM in it, Pi will haveto shoulder the costs ($millions) of layout, debugging, and foundry. I can't see that happening. Therefore any improvements in whatever *nix is used, those will need to be backtracked, even degraded, spending time undoing upgrades in future releases, ironically to keep the OS in the Pi up to date.
Considering how Pi was developed from the start, i'd think the original 2-chip Pi was a better hardware design, and more future-proofed, and easier to code for, than the existing 1-chip design is. The VIC-20 to C64 trip was also about chip integration and cost, even while adding a few bells and whistles, and it also caused issues. After a couple more ARM versions, or a couple more OS versions, it's real likely the Pi will be an orphan. At least with the 2-chip Pi, and the C64, you could plug in different cpus. Much like there were clones muddying the waters in the early 1980's, there's Pi clones now too, it's deja vu all over again. And i am saddened to see it happening, it is like a cruel joke.
If new reports are to be believed, it is very much easier now, a year after the Pi was introduced, to boot and run the Pi using Raspbian (not necessarily so with other OSs), but there's still no OS or apps included, you need another computer and ram chip to start up the Pi.
useless
40. Re: ARM and Position Independent Code
- Posted by rkdavis Mar 06, 2013
- 2273 views
[ Ah. Ok. Let me clarify, maybe. . .
I was going back to the development of the Pi, when it was two chips, an ARM (any ARM, pick an ARM, maybe a new one?) and a video chip. Back then one had full access to the ARM and to the video processing, this isn't so with the current Pi (have you read the data sheet on that chip?). It was possible to add more external memory, after a fashion, now it isn't. To me, it's like looking at the existing Pi (vs the original Pi) and the C64 (vs the VIC20) and asking myself why they shot themselves in the foot while doing the upgrade. Anyhow, all that work was thrown out. Pi v2 was initially programmed with Fedora, then Debian was backtracked from ARM7 to ARM6 to make Raspbian, and other *nixes were also modified to various results. There's likely an army of people working alone or small groups to make the Pi useable on the version of *nix they prefer, that won't be able to run this, that, or the other thing from one Pi to the next. AFAIK, only Raspbian uses the Broadcom chip's floating point math hardware.
While designing software to a specific piece of hardware is easier (in my experience) than designing software for multiple OSs on various hardware (like Euphoria is), there was still 1000's of man-hours put into just backtracking Debian to be Raspbian, and that alone is more than all the effort put into the ARM1, near as i can tell, and that is not including the work to bring about Debian or Fedora in the first place! It's just an astonishing amount of work, when compared to the same goal of making an entry level computer 30 years ago.
It's highly unlikely Broadcom will put a ARM8 or 9 into the same package the Pi uses now, and they are so closely coupled to suit Broadcom's needs that even if Pi gets a free license to make a new chip with new ARM in it, Pi will haveto shoulder the costs ($millions) of layout, debugging, and foundry. I can't see that happening. Therefore any improvements in whatever *nix is used, those will need to be backtracked, even degraded, spending time undoing upgrades in future releases, ironically to keep the OS in the Pi up to date.
Considering how Pi was developed from the start, i'd think the original 2-chip Pi was a better hardware design, and more future-proofed, and easier to code for, than the existing 1-chip design is. The VIC-20 to C64 trip was also about chip integration and cost, even while adding a few bells and whistles, and it also caused issues. After a couple more ARM versions, or a couple more OS versions, it's real likely the Pi will be an orphan. At least with the 2-chip Pi, and the C64, you could plug in different cpus. Much like there were clones muddying the waters in the early 1980's, there's Pi clones now too, it's deja vu all over again. And i am saddened to see it happening, it is like a cruel joke.
If new reports are to be believed, it is very much easier now, a year after the Pi was introduced, to boot and run the Pi using Raspbian (not necessarily so with other OSs), but there's still no OS or apps included, you need another computer and ram chip to start up the Pi.
useless
I'm beginning to think you have a problem with the raspberry pi. did one steal your boyfriend? :)
I initially wasn't going to respond to your missive as this is the openeuphoria forum not the raspberry pi forums but you are incorrect in so many ways that i have to respond in case anyone actually believes you.
The raspberry pi was never a 2 chip system (arm + separate video), not even the 2006 perf board prototype using an ATmega644. There is no version 2 raspberry pi. there are revisions 1, 1.1 & 2 which vary only by minor tweaks to the hardware such as ram, mounting holes & a polyfuse or two. you could classify the alpha and beta boards as versions if you wished but as only 50 & 80 of those exist and they used the same SOC and well they were alpha and beta versions not version 1.0. Pretty much any debian package you care to name that can be made to run on arm (e.g. isn't using tons of x86 assembly) runs on the raspberry pi. At least 35,000 (from the old list i have on my hd). There is at least Arch using hardware floating point as well. Broadcom already have newer SOCs with ARMv7 in the same formfactor that could pretty much be drop in replacements for the raspberry pi's current SOC. a bit of reworking might be required but as Eben has stated that there will be no upgrade to the raspberry pi other than hardware tweaks & bug fixes until 2015 at the least we'll see what is available then.
41. Re: ARM and Position Independent Code
- Posted by useless_ Mar 06, 2013
- 2288 views
- Last edited Mar 07, 2013
Some stuff about the Pi.
I'm beginning to think you have a problem with the raspberry pi. did one steal your boyfriend? :)
I initially wasn't going to respond to your missive as this is the openeuphoria forum not the raspberry pi forums but you are incorrect in so many ways that i have to respond in case anyone actually believes you.
The raspberry pi was never a 2 chip system (arm + separate video), not even the 2006 perf board prototype using an ATmega644.
You are saying the ATmega644, all by it's lonesome, generated the video and ran an OS with apps too? Didn't that perfboard have at least 2 other chips on it? I am sure it did, ask Eben. I am picturing the small perfbd with three DIP chips side by side across it.
I'd like to point out that older data online is being covered over (updated, replaced, etc as time marches by), and even
http://en.wikipedia.org/wiki/FileFile:Raspberry_Pi_board_at_TransferSummit_2011_cropped.jpg
is saying that pic is of a Model A, when the Model A had no ethernet, and that plainly does. All i am finding online in 2-chips now is the first and the current version with ethernet, which by then had the RAM-GPU chip. But pre-release, i remember reading everyone there was quite pleased they found the integrated Broadcom chip, and could reduce chip count.
There is no version 2 raspberry pi. there are revisions 1, 1.1 & 2 which vary only by minor tweaks to the hardware such as ram,
Initial sales commenced 29 February 2012[50] at 06:00 UTC;. At the same time, it was announced that the Model A, originally to have had 128 MB of RAMI don't consider going from 128MB to 512MB minor, given they want to run a full *nix on it, with apps. Even 512MB limit is annoying, considering that the virtual address space is 4GB using the MMU in the Broadcom chip. Sadly, the 32bit ARM chip has what.. only 27 address lines? Wasn't there a line in the datasheet about executeable code needing to be in the bottom 67MB (2^26) of ram?
mounting holes & a polyfuse or two. you could classify the alpha and beta boards as versions if you wished but as only 50 & 80 of those exist and they used the same SOC and well they were alpha and beta versions not version 1.0. Pretty much any debian package you care to name that can be made to run on arm (e.g. isn't using tons of x86 assembly) runs on the raspberry pi. At least 35,000 (from the old list i have on my hd).
There's 30,000 Debian versions? This from Wikipedia:
The ARM11 is based on version 6 of the ARM architecture (ARMv6), which due to its age is no longer supported by several popular versions of Linux, including Ubuntu which dropped support for processors below ARMv7 in 2009.[91]I am not counting RiscOS, mostly because it was developed in the 1980's specifically for the ARM.
There is at least Arch using hardware floating point as well. Broadcom already have newer SOCs with ARMv7 in the same formfactor that could pretty much be drop in replacements for the raspberry pi's current SOC. a bit of reworking might be required but as Eben has stated that there will be no upgrade to the raspberry pi other than hardware tweaks & bug fixes until 2015 at the least we'll see what is available then.
That would be nice. Then they can also fix that audio pin swap issue. I heard someone recently got Android installed painlessly. I am certainly not an expert on the Pi, i wish i could use it, but i'm not into *nix, C, C+, or Python and have other things to do than climb another learning curve. Ditto all the other ARM-based SBC out there. I wasn't going to say anything about the Pi other than my first post.
useless
42. Re: ARM and Position Independent Code
- Posted by EUWX Mar 06, 2013
- 2282 views
- Last edited Mar 07, 2013
[ Ah. Ok. Let me clarify, maybe. . .
I was going back to the development of the Pi, when it was two chips, an ARM (any ARM, pick an ARM, maybe a new one?) and a video chip. Back then one had full access to the ARM and to the video processing, this isn't so with the current Pi (have you read the data sheet on that chip?). It was possible to add more external memory, after a fashion, now it isn't. To me, it's like looking at the existing Pi (vs the original Pi) and the C64 (vs the VIC20) and asking myself why they shot themselves in the foot while doing the upgrade. Anyhow, all that work was thrown out. Pi v2 was initially programmed with Fedora, then Debian was backtracked from ARM7 to ARM6 to make Raspbian, and other *nixes were also modified to various results. There's likely an army of people working alone or small groups to make the Pi useable on the version of *nix they prefer, that won't be able to run this, that, or the other thing from one Pi to the next. AFAIK, only Raspbian uses the Broadcom chip's floating point math hardware.
While designing software to a specific piece of hardware is easier (in my experience) than designing software for multiple OSs on various hardware (like Euphoria is), there was still 1000's of man-hours put into just backtracking Debian to be Raspbian, and that alone is more than all the effort put into the ARM1, near as i can tell, and that is not including the work to bring about Debian or Fedora in the first place! It's just an astonishing amount of work, when compared to the same goal of making an entry level computer 30 years ago.
It's highly unlikely Broadcom will put a ARM8 or 9 into the same package the Pi uses now, and they are so closely coupled to suit Broadcom's needs that even if Pi gets a free license to make a new chip with new ARM in it, Pi will haveto shoulder the costs ($millions) of layout, debugging, and foundry. I can't see that happening. Therefore any improvements in whatever *nix is used, those will need to be backtracked, even degraded, spending time undoing upgrades in future releases, ironically to keep the OS in the Pi up to date.
Considering how Pi was developed from the start, i'd think the original 2-chip Pi was a better hardware design, and more future-proofed, and easier to code for, than the existing 1-chip design is. The VIC-20 to C64 trip was also about chip integration and cost, even while adding a few bells and whistles, and it also caused issues. After a couple more ARM versions, or a couple more OS versions, it's real likely the Pi will be an orphan. At least with the 2-chip Pi, and the C64, you could plug in different cpus. Much like there were clones muddying the waters in the early 1980's, there's Pi clones now too, it's deja vu all over again. And i am saddened to see it happening, it is like a cruel joke.
If new reports are to be believed, it is very much easier now, a year after the Pi was introduced, to boot and run the Pi using Raspbian (not necessarily so with other OSs), but there's still no OS or apps included, you need another computer and ram chip to start up the Pi.
useless
I'm beginning to think you have a problem with the raspberry pi. did one steal your boyfriend? :)
I initially wasn't going to respond to your missive as this is the openeuphoria forum not the raspberry pi forums but you are incorrect in so many ways that i have to respond in case anyone actually believes you.
The raspberry pi was never a 2 chip system (arm + separate video), not even the 2006 perf board prototype using an ATmega644. There is no version 2 raspberry pi. there are revisions 1, 1.1 & 2 which vary only by minor tweaks to the hardware such as ram, mounting holes & a polyfuse or two. you could classify the alpha and beta boards as versions if you wished but as only 50 & 80 of those exist and they used the same SOC and well they were alpha and beta versions not version 1.0. Pretty much any debian package you care to name that can be made to run on arm (e.g. isn't using tons of x86 assembly) runs on the raspberry pi. At least 35,000 (from the old list i have on my hd). There is at least Arch using hardware floating point as well. Broadcom already have newer SOCs with ARMv7 in the same form factor that could pretty much be drop in replacements for the raspberry pi's current SOC. a bit of reworking might be required but as Eben has stated that there will be no upgrade to the raspberry pi other than hardware tweaks & bug fixes until 2015 at the least we'll see what is available then.
RKD: Sure, 6502 was similar to 6800 and some of the fundamental were similar to 8008 (all 8 bit processors). I have worked with these processors using machine language, and switched to Z80 instead of 8088, and later switched to 8086. it was after 8086 that I stopped using machine code and used assembler. I also had the privilege (and paid handsomely for it too) of "porting" commodore Basic language program which used a lot of assembler calls, to IBM PC and adding matching 8088 Assembler code.
But today I would not say the Pentium P4 is the same as the original 8008 processor, nor would I expect anybody with any sense, to compare ARM v6 and 6502. The root of the current P4 might have been the original 8008 just as the basic design of ARMv6 might have some resemblance to 6502 (though I doubt it) but to call a modern 32 bit CPU with enormous video capability the same as C64 is to commit a sin worthy of inviting a lynch mob to attack, if such a comment was made in an more frequented CPU related forum.
I tried to bring to the notice of those interested, the fusion of CPU related work and streaming video related work. The existence of CUDA (for Nokia) and OPENCL for all video processors is a pointer to the direction of thought that eventually ended in the modern day ubiquitous powerful phones and tablets, and I am very right in saying that they have shaken up Microsoft.
The separation of CPU type of work and video chip work, does not exist in the ARM world. For those who are more inquisitive about the future, the integration of network related hardware on the same chip is the current thrust as seen in the Calxeda chip ( http://www.calxeda.com/ ) where again ARM is in the lead. Intel belated has tried to introduce their SOC but it is much more power hungry, though claiming superiority from being 64 bit.
Interested people should also look at Adapteva ( http://www.adapteva.com/ ) parallel processing board for $99, because something like that is the future direction of computing and more importantly of HOBBY COMPUTING.
Somebody also said, that there is too much thrust in this forum towards rejecting Windows. I am a Windows person, so I would not be rejecting Windows. However, one cannot doubt the enormous intrusion Linux has made into all kinds of computing devices; one cannot doubt that it is free and easy to obtain; one cannot doubt that Linux, once you know how to harness it, has a lot of pre-done application software in the Open source world; and one cannot doubt that as of now there is no Windows OS available for ARM processors.
43. Re: ARM and Position Independent Code
- Posted by rkdavis Mar 06, 2013
- 2274 views
ye gods and little fishes talk diliberately twisting facts and selective cutting and pasting.
so shall we do this in a civilized manner or do i just call you a troll and have done with it?
ok lets start
You are saying the ATmega644, all by it's lonesome, generated the video and ran an OS with apps too? Didn't that perfboard have at least 2 other chips on it? I am sure it did, ask Eben. I am picturing the small perfbd with three DIP chips side by side across it.
I'd like to point out that older data online is being covered over (updated, replaced, etc as time marches by), and even http://en.wikipedia.org/wiki/FileFileFile:Raspberry_Pi_board_at_TransferSummit_2011_cropped.jpg is saying that pic is of a Model A, when the Model A had no ethernet, and that plainly does. All i am finding online in 2-chips now is the first and the current version with ethernet, which by then had the RAM-GPU chip. But pre-release, i remember reading everyone there was quite pleased they found the integrated Broadcom chip, and could reduce chip count.
To quote Eben, the designer http://www.raspberrypi.org/archives/264
These boards use an Atmel ATmega644 microcontroller clocked at 22.1MHz, and a 512K SRAM for data and framebuffer storage. 19 of the Atmel’s 32 GPIO lines are used to drive the SRAM address bus. To generate a 320×240 component video signal, the Atmel rapidly increments the address, and the data lines are fed via 74HC-series buffers to a trio of simple summing-point DACs; during horizontal and vertical blanking, it is free to perform other operations.
Nothing about separate video chip there is there?
and even http://en.wikipedia.org/wiki/FileFileFile:Raspberry_Pi_board_at_TransferSummit_2011_cropped.jpg is saying that pic is of a Model A, when the Model A had no ethernet, and that plainly does.
Well for a start that is a beta board and not a Model A. You do know that the Model A wasn't released until a month ago don't you? so no photo from 2011 could possibly be a Model A no matter what wikipedia or anyone else claims.
Initial sales commenced 29 February 2012[50] at 06:00 UTC;. At the same time, it was announced that the Model A, originally to have had 128 MB of RAM
do you think you could paste the whole quote?
Initial sales commenced 29 February 2012[50] at 06:00 UTC;. At the same time, it was announced that the Model A, originally to have had 128 MB of RAM, was to be upgraded to 256 MB before release.
There's 30,000 Debian versions?
I didn't say versions I said packages
Pretty much any debian package you care to name that can be made to run on arm (e.g. isn't using tons of x86 assembly) runs on the raspberry pi. At least 35,000
see: http://www.raspbian.org/FrontPage
oh dear this is getting boring so for my final trick
but i got poked, or baited, or annoyed by someone.
no you didn't you got shown to be a troll of the highest order. it's been fun and i could go and refute every claim you've made but it's beginning to get boring now as it's too easy to show you up so i'll leave it at that and let others decide if you are worth reading at least when ARM or the Raspberry Pi is being discussed.
44. Re: ARM and Position Independent Code
- Posted by useless_ Mar 06, 2013
- 2267 views
- Last edited Mar 07, 2013
To quote Eben, the designer http://www.raspberrypi.org/archives/264
These boards use an Atmel ATmega644 microcontroller clocked at 22.1MHz, and a 512K SRAM for data and framebuffer storage. 19 of the Atmel’s 32 GPIO lines are used to drive the SRAM address bus. To generate a 320×240 component video signal, the Atmel rapidly increments the address, and the data lines are fed via 74HC-series buffers to a trio of simple summing-point DACs; during horizontal and vertical blanking, it is free to perform other operations.
Nothing about separate video chip there is there?
It's my understanding they realised the trick of running the apps only during v-interval, like the ZX80 did, was too slow. They went with ARM, and then discovered the Broadcom chip AFTER there was an ARM in the house for prototyping. They didn't go straight from the avr to the Broadcom chip.
and even http://en.wikipedia.org/wiki/FileFileFile:Raspberry_Pi_board_at_TransferSummit_2011_cropped.jpg is saying that pic is of a Model A, when the Model A had no ethernet, and that plainly does.
Well for a start that is a beta board and not a Model A. You do know that the Model A wasn't released until a month ago don't you? so no photo from 2011 could possibly be a Model A no matter what wikipedia or anyone else claims.
Yea, i was saying that, and in context of, saying the older documents are disappearing, and things are getting mixed up, even in Wikipedia. I am glad you caught that, oh, you didn't.
Initial sales commenced 29 February 2012[50] at 06:00 UTC;. At the same time, it was announced that the Model A, originally to have had 128 MB of RAM
do you think you could paste the whole quote?
The remainder of the text i was quoting from had absolutely nothing to do with showing the start of the memory progression STARTED with a measely 128MB of ram.
There's 30,000 Debian versions?
I didn't say versions I said packages
I was talking about versions.
useless