1. ARM and Position Independent Code

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

new topic     » topic index » view message » categorize

2. Re: ARM and Position Independent Code

i believe it does at least all the 3rd party libs (.so) i've built have -fPIC in their makefile.

new topic     » goto parent     » topic index » view message » categorize

3. Re: ARM and Position Independent Code

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

D

new topic     » goto parent     » topic index » view message » categorize

4. Re: ARM and Position Independent Code

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

new topic     » goto parent     » topic index » view message » categorize

5. Re: ARM and Position Independent Code

rkdavis said...

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

D

I wouldn't be suprised if, for example, the answer was different on ARMv5 and ARMv6.

new topic     » goto parent     » topic index » view message » categorize

6. Re: ARM and Position Independent Code

jimcbrown said...

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

new topic     » goto parent     » topic index » view message » categorize

7. Re: ARM and Position Independent Code

mattlewis said...

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.

new topic     » goto parent     » topic index » view message » categorize

8. Re: ARM and Position Independent Code

EUWX said...
mattlewis said...

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.

new topic     » goto parent     » topic index » view message » categorize

9. Re: ARM and Position Independent Code

mattlewis said...

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

new topic     » goto parent     » topic index » view message » categorize

10. Re: ARM and Position Independent Code

Jerome said...

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/

mattlewis said...

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).

new topic     » goto parent     » topic index » view message » categorize

11. Re: ARM and Position Independent Code

mattlewis said...

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?

new topic     » goto parent     » topic index » view message » categorize

12. Re: ARM and Position Independent Code

jimcbrown said...
mattlewis said...

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

new topic     » goto parent     » topic index » view message » categorize

13. Re: ARM and Position Independent Code

mattlewis said...
jimcbrown said...
mattlewis said...

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?

new topic     » goto parent     » topic index » view message » categorize

14. Re: ARM and Position Independent Code


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

new topic     » goto parent     » topic index » view message » categorize

15. Re: ARM and Position Independent Code

useless_ said...

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

new topic     » goto parent     » topic index » view message » categorize

16. Re: ARM and Position Independent Code

mattlewis said...
useless_ said...

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

new topic     » goto parent     » topic index » view message » categorize

17. Re: ARM and Position Independent Code

eukat said...

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...)

new topic     » goto parent     » topic index » view message » categorize

18. Re: ARM and Position Independent Code

jimcbrown said...

(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.

new topic     » goto parent     » topic index » view message » categorize

19. Re: ARM and Position Independent Code

useless_ said...
mattlewis said...
useless_ said...

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.

new topic     » goto parent     » topic index » view message » categorize

20. Re: ARM and Position Independent Code

jimcbrown said...

(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.

new topic     » goto parent     » topic index » view message » categorize

21. Re: ARM and Position Independent Code

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.

new topic     » goto parent     » topic index » view message » categorize

22. Re: ARM and Position Independent Code

useless_ said...

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.

useless_ said...

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. blink

-Greg

new topic     » goto parent     » topic index » view message » categorize

23. Re: ARM and Position Independent Code

EUWX said...

Some stuff about ARM and graphics.

The chip on the Pi is a graphics processor and an ARM on one chip.

EUWX said...

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

new topic     » goto parent     » topic index » view message » categorize

24. Re: ARM and Position Independent Code

jaygade said...

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).

jaygade said...

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

new topic     » goto parent     » topic index » view message » categorize

25. Re: ARM and Position Independent Code

useless_ said...
jaygade said...

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.

jaygade said...
useless said...

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?

new topic     » goto parent     » topic index » view message » categorize

26. Re: ARM and Position Independent Code

jaygade said...
useless_ said...
jaygade said...

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.

jaygade said...
useless said...
jaygade said...

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

new topic     » goto parent     » topic index » view message » categorize

27. Re: ARM and Position Independent Code

useless_ said...

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.

useless said...
jaygade said...

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.

useless said...



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.

new topic     » goto parent     » topic index » view message » categorize

28. Re: ARM and Position Independent Code

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

new topic     » goto parent     » topic index » view message » categorize

29. Re: ARM and Position Independent Code

eukat said...

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.

new topic     » goto parent     » topic index » view message » categorize

30. Re: ARM and Position Independent Code

jimcbrown said...
eukat said...

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

new topic     » goto parent     » topic index » view message » categorize

31. Re: ARM and Position Independent Code

jimcbrown said...
eukat said...

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

new topic     » goto parent     » topic index » view message » categorize

32. Re: ARM and Position Independent Code

mattlewis said...
jimcbrown said...
eukat said...

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

new topic     » goto parent     » topic index » view message » categorize

33. Re: ARM and Position Independent Code

eukat said...
jimcbrown said...
eukat said...

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.

new topic     » goto parent     » topic index » view message » categorize

34. Re: ARM and Position Independent Code

jimcbrown said...
eukat said...
jimcbrown said...

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.

new topic     » goto parent     » topic index » view message » categorize

35. Re: ARM and Position Independent Code

useless_ said...

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.

useless_ said...

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

new topic     » goto parent     » topic index » view message » categorize

36. OT: ARM and Position Independent Code

jaygade said...

I'm the simpleton in question

You'll never be a simpleton to me.

new topic     » goto parent     » topic index » view message » categorize

37. Re: ARM and Position Independent Code

mattlewis said...
useless_ said...

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

new topic     » goto parent     » topic index » view message » categorize

38. Re: ARM and Position Independent Code

useless_ said...
mattlewis said...
useless_ said...

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

new topic     » goto parent     » topic index » view message » categorize

39. Re: ARM and Position Independent Code

mattlewis said...
useless_ said...
mattlewis said...
useless_ said...

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

new topic     » goto parent     » topic index » view message » categorize

40. Re: ARM and Position Independent Code

useless_ said...

[ 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.

new topic     » goto parent     » topic index » view message » categorize

41. Re: ARM and Position Independent Code

rkdavis said...
useless_ said...

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.

rkdavis said...

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 RAM 
I 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?

rkdavis said...

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.

rkdavis said...

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

new topic     » goto parent     » topic index » view message » categorize

42. Re: ARM and Position Independent Code

rkdavis said...
useless_ said...

[ 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.

new topic     » goto parent     » topic index » view message » categorize

43. Re: ARM and Position Independent Code

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

useless said...

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?

useless said...

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.

useless said...
said...

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?

said...

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.

useless said...

There's 30,000 Debian versions?

I didn't say versions I said packages

rkdavis said...

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

useless said...

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.

new topic     » goto parent     » topic index » view message » categorize

44. Re: ARM and Position Independent Code

rkdavis said...

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.

rkdavis said...
useless said...

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.

rkdavis said...
said...

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.

rkdavis said...
useless said...

There's 30,000 Debian versions?

I didn't say versions I said packages

I was talking about versions.

useless

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu