Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #71667 > unrolled thread

pure c on smartphones (and other devices)

Back to article view | Back to comp.lang.c

Contents

  pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-03 08:32 -0700
    pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 09:19 -0700
      Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-03 09:58 -0700
        Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 10:20 -0700
          Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-03 10:34 -0700
            Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 10:40 -0700
              Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-03 11:30 -0700
                Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-03 11:43 -0700
        Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 10:24 -0700
          Re: pure c on smartphones (and other devices) Johann Klammer <klammerj@NOSPAM.a1.net> - 2015-10-03 20:18 +0200
            Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 11:23 -0700
    Re: pure c on smartphones (and other devices) Aleksandar Kuktin <akuktin@gmail.com> - 2015-10-04 12:31 +0000
      Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-04 05:45 -0700
        Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-04 05:53 -0700
          Re: pure c on smartphones (and other devices) supercat@casperkitty.com - 2015-10-05 10:52 -0700
            Re: pure c on smartphones (and other devices) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 22:18 +0000
              Re: pure c on smartphones (and other devices) supercat@casperkitty.com - 2015-10-05 16:16 -0700
                Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-06 00:27 +0100
                  Re: pure c on smartphones (and other devices) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-06 10:50 +0100
                    Re: pure c on smartphones (and other devices) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-06 10:47 +0000
                    Re: pure c on smartphones (and other devices) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-06 12:31 +0100
                    Re: pure c on smartphones (and other devices) supercat@casperkitty.com - 2015-10-06 09:18 -0700
                      Re: pure c on smartphones (and other devices) Rosario19 <Ros@invalid.invalid> - 2015-10-06 18:30 +0200
                        Re: pure c on smartphones (and other devices) supercat@casperkitty.com - 2015-10-06 10:14 -0700
                      Re: pure c on smartphones (and other devices) Waldek Hebisch <antispam@math.uni.wroc.pl> - 2015-10-09 18:32 +0000
                        Re: pure c on smartphones (and other devices) supercat@casperkitty.com - 2015-10-09 13:02 -0700
                Re: pure c on smartphones (and other devices) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-06 03:25 +0000
        Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-04 06:27 -0700
          Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-04 06:58 -0700
      Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-04 06:01 -0700
        Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-04 15:33 +0100
          Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-04 07:58 -0700
            Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-04 08:13 -0700
          Re: pure c on smartphones (and other devices) Keith Thompson <kst-u@mib.org> - 2015-10-04 15:42 -0700
            Re: pure c on smartphones (and other devices) David Brown <david.brown@hesbynett.no> - 2015-10-05 09:03 +0200
              Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-05 11:24 +0100
                Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-05 11:27 +0100
              Re: pure c on smartphones (and other devices) Keith Thompson <kst-u@mib.org> - 2015-10-05 09:29 -0700
              Re: pure c on smartphones (and other devices) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-06 03:31 -0700
                Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-06 12:29 +0100
                  Re: pure c on smartphones (and other devices) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-06 07:18 -0700
                    Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-06 18:33 +0100
                      Re: pure c on smartphones (and other devices) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-06 11:07 -0700
                        Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-07 12:53 +0100
                          Re: pure c on smartphones (and other devices) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-07 06:33 -0700
                            Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-07 18:21 +0100
                              Re: pure c on smartphones (and other devices) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-07 19:10 -0700
    Re: pure c on smartphones (and other devices) Ayan <selfjam@gmail.com> - 2015-10-07 13:41 -0400
      Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-07 14:01 -0700
        Re: pure c on smartphones (and other devices) Ayan <selfjam@gmail.com> - 2015-10-07 23:09 -0400
          Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-08 02:26 -0700
          Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-08 11:01 +0100
            Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-08 03:29 -0700
              Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-08 12:19 +0100
                Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-08 05:42 -0700
                  Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-08 14:41 +0100
                    Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-08 06:55 -0700
                      Re: pure c on smartphones (and other devices) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-08 08:53 -0700
                        Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-08 09:21 -0700
                          Re: pure c on smartphones (and other devices) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-08 09:46 -0700
                            Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-08 10:07 -0700
                              Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-11 23:58 -0700
                          Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-09 04:41 -0700
                Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-08 05:59 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#71667 — pure c on smartphones (and other devices)

I once tried one day to setup android coding environment but was 'dispelled' by that (to big to 'messy' javalike sh*t, xml-s, meaningfull folder names etc )

I long for real pure c coding on devices - which is like you produce binary able to execute run it and here you go..

have someone knows something on this things (pure c on devices) I got no biger (or even smaller) picture on this things,

[toc] | [next] | [standalone]

#71672

I have only found commercial C compilers which
I've gotten to work on Android. They worked just
fine. I was able to port Van Smith's open source
benchmark and get it to compile and run.  It only
used stdout and compute.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#71683

W dniu sobota, 3 października 2015 18:20:08 UTC+2 użytkownik Rick C. Hodgin napisał:
> I have only found commercial C compilers which
> I've gotten to work on Android. They worked just
> fine. I was able to port Van Smith's open source
> benchmark and get it to compile and run.  It only
> used stdout and compute.
> 
> Best regards,
> Rick C. Hodgin

did they produced native assembly binaries
you run native on phones cpu or this was 
some mix ow java virtual machine or what?
do andriod expose some native c apis to use?
(got no idea asc for curiosity)

[toc] | [prev] | [next] | [standalone]

#71686

On Saturday, October 3, 2015 at 12:59:10 PM UTC-4, fir wrote:
> W dniu sobota, 3 października 2015 18:20:08 UTC+2 użytkownik Rick C. Hodgin napisał:
> > I have only found commercial C compilers which
> > I've gotten to work on Android. They worked just
> > fine. I was able to port Van Smith's open source
> > benchmark and get it to compile and run.  It only
> > used stdout and compute.
> > 
> > Best regards,
> > Rick C. Hodgin
> 
> did they produced native assembly binaries
> you run native on phones cpu or this was 
> some mix ow java virtual machine or what?
> do andriod expose some native c apis to use?
> (got no idea asc for curiosity)

Native binaries.  I used a shell program and ran the compiled program
as ./progname.  It ran for several minutes on the benchmark, and wrote
output at various stages showing computation time and progression.

COSBI is the benchmark he wrote:

     http://www.vanshardware.com/files/

It's the one I compiled on Android.  It took a few changes in the code
to get it to compile, but it compiled without issue.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#71689

W dniu sobota, 3 października 2015 19:20:19 UTC+2 użytkownik Rick C. Hodgin napisał:
> On Saturday, October 3, 2015 at 12:59:10 PM UTC-4, fir wrote:
> > W dniu sobota, 3 października 2015 18:20:08 UTC+2 użytkownik Rick C. Hodgin napisał:
> > > I have only found commercial C compilers which
> > > I've gotten to work on Android. They worked just
> > > fine. I was able to port Van Smith's open source
> > > benchmark and get it to compile and run.  It only
> > > used stdout and compute.
> > > 
> > > Best regards,
> > > Rick C. Hodgin
> > 
> > did they produced native assembly binaries
> > you run native on phones cpu or this was 
> > some mix ow java virtual machine or what?
> > do andriod expose some native c apis to use?
> > (got no idea asc for curiosity)
> 
> Native binaries.  I used a shell program and ran the compiled program
> as ./progname.  It ran for several minutes on the benchmark, and wrote
> output at various stages showing computation time and progression.
> 
> COSBI is the benchmark he wrote:
> 
>      http://www.vanshardware.com/files/
> 
> It's the one I compiled on Android.  It took a few changes in the code
> to get it to compile, but it compiled without issue.
> 
> Best regards,
> Rick C. Hodgin

If i would get an easy way to compile c sources on desktop and run it on android
phone i could try it.. this android sdk on
eclipse is still rather awfull to me

[toc] | [prev] | [next] | [standalone]

#71691

On Saturday, October 3, 2015 at 1:34:35 PM UTC-4, fir wrote:
> W dniu sobota, 3 października 2015 19:20:19 UTC+2 użytkownik Rick C. Hodgin napisał:
> > On Saturday, October 3, 2015 at 12:59:10 PM UTC-4, fir wrote:
> > > W dniu sobota, 3 października 2015 18:20:08 UTC+2 użytkownik Rick C. Hodgin napisał:
> > > > I have only found commercial C compilers which
> > > > I've gotten to work on Android. They worked just
> > > > fine. I was able to port Van Smith's open source
> > > > benchmark and get it to compile and run.  It only
> > > > used stdout and compute.
> > > > 
> > > > Best regards,
> > > > Rick C. Hodgin
> > > 
> > > did they produced native assembly binaries
> > > you run native on phones cpu or this was 
> > > some mix ow java virtual machine or what?
> > > do andriod expose some native c apis to use?
> > > (got no idea asc for curiosity)
> > 
> > Native binaries.  I used a shell program and ran the compiled program
> > as ./progname.  It ran for several minutes on the benchmark, and wrote
> > output at various stages showing computation time and progression.
> > 
> > COSBI is the benchmark he wrote:
> > 
> >      http://www.vanshardware.com/files/
> > 
> > It's the one I compiled on Android.  It took a few changes in the code
> > to get it to compile, but it compiled without issue.
> > 
> > Best regards,
> > Rick C. Hodgin
> 
> If i would get an easy way to compile c sources on desktop and run it on android
> phone i could try it.. this android sdk on
> eclipse is still rather awfull to me

If you can get a proper cross-compiler to generate the binary, then
there is an ssh-like utility available with the Eclipse developer
environment you can use to scp your code onto the remote device.

I have used that also to install custom mods over the years.

FWIW, installing the compiler on the Android device itself was a
very easy solution.  And if you can get ssh access to it, you can
do the editing on your desktop, scp to the remote, and compile on
the remote.  For small projects it would work well.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#71698

W dniu sobota, 3 października 2015 19:40:40 UTC+2 użytkownik Rick C. Hodgin napisał:
> On Saturday, October 3, 2015 at 1:34:35 PM UTC-4, fir wrote:
> > W dniu sobota, 3 października 2015 19:20:19 UTC+2 użytkownik Rick C. Hodgin napisał:
> > > On Saturday, October 3, 2015 at 12:59:10 PM UTC-4, fir wrote:
> > > > W dniu sobota, 3 października 2015 18:20:08 UTC+2 użytkownik Rick C. Hodgin napisał:
> > > > > I have only found commercial C compilers which
> > > > > I've gotten to work on Android. They worked just
> > > > > fine. I was able to port Van Smith's open source
> > > > > benchmark and get it to compile and run.  It only
> > > > > used stdout and compute.
> > > > > 
> > > > > Best regards,
> > > > > Rick C. Hodgin
> > > > 
> > > > did they produced native assembly binaries
> > > > you run native on phones cpu or this was 
> > > > some mix ow java virtual machine or what?
> > > > do andriod expose some native c apis to use?
> > > > (got no idea asc for curiosity)
> > > 
> > > Native binaries.  I used a shell program and ran the compiled program
> > > as ./progname.  It ran for several minutes on the benchmark, and wrote
> > > output at various stages showing computation time and progression.
> > > 
> > > COSBI is the benchmark he wrote:
> > > 
> > >      http://www.vanshardware.com/files/
> > > 
> > > It's the one I compiled on Android.  It took a few changes in the code
> > > to get it to compile, but it compiled without issue.
> > > 
> > > Best regards,
> > > Rick C. Hodgin
> > 
> > If i would get an easy way to compile c sources on desktop and run it on android
> > phone i could try it.. this android sdk on
> > eclipse is still rather awfull to me
> 
> If you can get a proper cross-compiler to generate the binary, then
> there is an ssh-like utility available with the Eclipse developer
> environment you can use to scp your code onto the remote device.
> 
> I have used that also to install custom mods over the years.
> 
> FWIW, installing the compiler on the Android device itself was a
> very easy solution.  And if you can get ssh access to it, you can
> do the editing on your desktop, scp to the remote, and compile on
> the remote.  For small projects it would work well.
> 
> Best regards,
> Rick C. Hodgin

well maybe.. best thing would be to get normal compiler.. i got no time to really read on it few days im afraid (also not sure as to belive, as android is java based, wonder if siome graphics and gui c apis are exposed

imo its shame that oldschool c coding is not 100% strightforward on devices (i dont know the details though)

[toc] | [prev] | [next] | [standalone]

#71701

W dniu sobota, 3 października 2015 20:30:58 UTC+2 użytkownik fir napisał:
> W dniu sobota, 3 października 2015 19:40:40 UTC+2 użytkownik Rick C. Hodgin napisał:
> > On Saturday, October 3, 2015 at 1:34:35 PM UTC-4, fir wrote:
> > > W dniu sobota, 3 października 2015 19:20:19 UTC+2 użytkownik Rick C. Hodgin napisał:
> > > > On Saturday, October 3, 2015 at 12:59:10 PM UTC-4, fir wrote:
> > > > > W dniu sobota, 3 października 2015 18:20:08 UTC+2 użytkownik Rick C. Hodgin napisał:
> > > > > > I have only found commercial C compilers which
> > > > > > I've gotten to work on Android. They worked just
> > > > > > fine. I was able to port Van Smith's open source
> > > > > > benchmark and get it to compile and run.  It only
> > > > > > used stdout and compute.
> > > > > > 
> > > > > > Best regards,
> > > > > > Rick C. Hodgin
> > > > > 
> > > > > did they produced native assembly binaries
> > > > > you run native on phones cpu or this was 
> > > > > some mix ow java virtual machine or what?
> > > > > do andriod expose some native c apis to use?
> > > > > (got no idea asc for curiosity)
> > > > 
> > > > Native binaries.  I used a shell program and ran the compiled program
> > > > as ./progname.  It ran for several minutes on the benchmark, and wrote
> > > > output at various stages showing computation time and progression.
> > > > 
> > > > COSBI is the benchmark he wrote:
> > > > 
> > > >      http://www.vanshardware.com/files/
> > > > 
> > > > It's the one I compiled on Android.  It took a few changes in the code
> > > > to get it to compile, but it compiled without issue.
> > > > 
> > > > Best regards,
> > > > Rick C. Hodgin
> > > 
> > > If i would get an easy way to compile c sources on desktop and run it on android
> > > phone i could try it.. this android sdk on
> > > eclipse is still rather awfull to me
> > 
> > If you can get a proper cross-compiler to generate the binary, then
> > there is an ssh-like utility available with the Eclipse developer
> > environment you can use to scp your code onto the remote device.
> > 
> > I have used that also to install custom mods over the years.
> > 
> > FWIW, installing the compiler on the Android device itself was a
> > very easy solution.  And if you can get ssh access to it, you can
> > do the editing on your desktop, scp to the remote, and compile on
> > the remote.  For small projects it would work well.
> > 
> > Best regards,
> > Rick C. Hodgin
> 
> well maybe.. best thing would be to get normal compiler.. i got no time to really read on it few days im afraid (also not sure as to belive, as android is java based, wonder if siome graphics and gui c apis are exposed
> 
> imo its shame that oldschool c coding is not 100% strightforward on devices (i dont know the details though)

as i understand what google says c coding on android is more or less glue where c is glued on top of java api (world is upside down here) -its shame, i need pure c

[toc] | [prev] | [next] | [standalone]

#71687

On Saturday, October 3, 2015 at 12:59:10 PM UTC-4, fir wrote:
> do andriod expose some native c apis to use?
> (got no idea asc for curiosity)

The C compiler I installed came with its own standard library support,
which I believe you would have to use.  There are probably several APIs
which are available on Android without standard libraries, but I do not
know about them.

The compiler I used was a C/C++ compiler.  It ran on two different
Android devices out of the box after installation.  I had no issues
compiling Android executables on the Android device.  I have, however,
had much difficulty trying to do cross-compilation for Android.  I've
never been able to get it to work reliably.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#71696

On 10/03/2015 07:24 PM, Rick C. Hodgin wrote:
> On Saturday, October 3, 2015 at 12:59:10 PM UTC-4, fir wrote:
>> do andriod expose some native c apis to use?
>> (got no idea asc for curiosity)
> 
> The C compiler I installed came with its own standard library support,
> which I believe you would have to use.  There are probably several APIs
> which are available on Android without standard libraries, but I do not
> know about them.
> 
> The compiler I used was a C/C++ compiler.  It ran on two different
> Android devices out of the box after installation.  I had no issues
> compiling Android executables on the Android device.  I have, however,
> had much difficulty trying to do cross-compilation for Android.  I've
> never been able to get it to work reliably.
> 
> Best regards,
> Rick C. Hodgin
> 
Isn't android just Googles name for LINUX?
They should have gcc?

[toc] | [prev] | [next] | [standalone]

#71697

On Saturday, October 3, 2015 at 2:18:52 PM UTC-4, Johann Klammer wrote:
> On 10/03/2015 07:24 PM, Rick C. Hodgin wrote:
> > On Saturday, October 3, 2015 at 12:59:10 PM UTC-4, fir wrote:
> >> do andriod expose some native c apis to use?
> >> (got no idea asc for curiosity)
> > 
> > The C compiler I installed came with its own standard library support,
> > which I believe you would have to use.  There are probably several APIs
> > which are available on Android without standard libraries, but I do not
> > know about them.
> > 
> > The compiler I used was a C/C++ compiler.  It ran on two different
> > Android devices out of the box after installation.  I had no issues
> > compiling Android executables on the Android device.  I have, however,
> > had much difficulty trying to do cross-compilation for Android.  I've
> > never been able to get it to work reliably.
> > 
> > Best regards,
> > Rick C. Hodgin
> > 
> Isn't android just Googles name for LINUX?
> They should have gcc?

It might.  It is a Linux OS.  I could not find a version of GCC that
would run on it, but I didn't do an exhaustive search.  If you find
one, please post it here as I too would like to have that asset.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#71797

On Sat, 03 Oct 2015 08:32:20 -0700, fir wrote:

> I once tried one day to setup android coding environment but was
> 'dispelled' by that (to big to 'messy' javalike sh*t, xml-s, meaningfull
> folder names etc )
> 
> I long for real pure c coding on devices - which is like you produce
> binary able to execute run it and here you go..
> 
> have someone knows something on this things (pure c on devices) I got no
> biger (or even smaller) picture on this things,

This is absolutely perfectly doable, although getting a GUI handle may be 
problematic.

The easiest way, and the one I did, is to use Android's kernel and ship 
your own userland. Basically, setup a cross-compiler on a seed host 
(desktop), compile the minimal userland, copy that userland onto the 
phone and let it recompile itself into a complete feature-full computing 
environment.

For this, you'll need a terminal (either find some Terminal app or ssh) 
and probably root. Shop around for a rootkit, they're easy to find. :)

Take a look at CLFS for pointers: http://www.linuxfromscratch.org/

[toc] | [prev] | [next] | [standalone]

#71799

W dniu niedziela, 4 października 2015 14:31:41 UTC+2 użytkownik Aleksandar Kuktin napisał:
> On Sat, 03 Oct 2015 08:32:20 -0700, fir wrote:
> 
> > I once tried one day to setup android coding environment but was
> > 'dispelled' by that (to big to 'messy' javalike sh*t, xml-s, meaningfull
> > folder names etc )
> > 
> > I long for real pure c coding on devices - which is like you produce
> > binary able to execute run it and here you go..
> > 
> > have someone knows something on this things (pure c on devices) I got no
> > biger (or even smaller) picture on this things,
> 
> This is absolutely perfectly doable, although getting a GUI handle may be 
> problematic.
> 
> The easiest way, and the one I did, is to use Android's kernel and ship 
> your own userland. Basically, setup a cross-compiler on a seed host 
> (desktop), compile the minimal userland, copy that userland onto the 
> phone and let it recompile itself into a complete feature-full computing 
> environment.
> 
> For this, you'll need a terminal (either find some Terminal app or ssh) 
> and probably root. Shop around for a rootkit, they're easy to find. :)
> 
> Take a look at CLFS for pointers: http://www.linuxfromscratch.org/

my personal trouble is i dont know nothing about linux.. but good to know such solution is avaliable, it sound that if i would be coding on linux i would take this route..
other trouble is to get the gui api or at least raw screen acces/blitter etc..
seem to be longer story though each such a longer story has probably its own hackish shortcuts..

[toc] | [prev] | [next] | [standalone]

#71801

In general i want alco complain that c was shuned from devices..  this is shame as i 
said.. maybe they improve wit time on it but
imo it was realy big mistake to expose only java code for user coders

[toc] | [prev] | [next] | [standalone]

#71994

On Sunday, October 4, 2015 at 7:54:12 AM UTC-5, fir wrote:
> imo it was realy big mistake to expose only java code for user coders

If a Java virtual machine is properly implemented, it will be possible for
the system to accept and run untrusted Java code in a sandbox [in practice,
many JVM implementations have security bugs].  Unless a C implementation
produces some for of intermediate code for a VM, it will be very difficult
for it to offer any significant security beyond what the OS can enforce,
and I don't think Linux was designed with the intention of providing robust
sandboxing.

That having been said, I don't think it would be possible to write a C to
bytecode compiler which would efficiently support the semantics that
people expect from C code; it would need to either use four byte values to
store each 32-bit value, or process byte loads and stores by continually
packing and unpacking things stored in 32-bit values.  The best performance
might come from having every group of four pointer-accessible bytes be
represented by five members of a "byte[]" and one member of an "int[]",
and using one byte to indicate whether:

1. The corresponding int[] item and byte[] items held identical data.
2. The int[] value was written last.
3. The byte[] values were written last.

Not terribly performant, but probably workable.  If C code could tolerate
having "char" be 32 bits, that would simplify things a lot, but would of
course break compatibility with a lot of code.

[toc] | [prev] | [next] | [standalone]

#72007

supercat@casperkitty.com wrote:
> On Sunday, October 4, 2015 at 7:54:12 AM UTC-5, fir wrote:
>> imo it was realy big mistake to expose only java code for user coders
 
> If a Java virtual machine is properly implemented, it will be possible for
> the system to accept and run untrusted Java code in a sandbox [in practice,
> many JVM implementations have security bugs].  Unless a C implementation
> produces some for of intermediate code for a VM, it will be very difficult
> for it to offer any significant security beyond what the OS can enforce,
> and I don't think Linux was designed with the intention of providing robust
> sandboxing.
 
> That having been said, I don't think it would be possible to write a C to
> bytecode compiler which would efficiently support the semantics that
> people expect from C code; it would need to either use four byte values to
> store each 32-bit value, or process byte loads and stores by continually
> packing and unpacking things stored in 32-bit values.  The best performance
> might come from having every group of four pointer-accessible bytes be
> represented by five members of a "byte[]" and one member of an "int[]",
> and using one byte to indicate whether:

I would be interested to see one where:

float *f;
f=malloc(100*sizeof(*f));
f[3]=3;

use JVM float and float array operations, and

int *p;
p=malloc(100*sizeof(*p));
p[3]=3;

used JVM int operations.

It gets more interesting if you:

memcpy(p, f, 100*sizeof(*f));

but it isn't hard for memcpy() to figure out the type
of its arguments and copy appropriately.

int *p;
p=malloc(100*sizeof(*f));
f=(float *) p;
f[3]=3;

is the case that really gets hard. 

but most C programs don't do that.
 
> 1. The corresponding int[] item and byte[] items held identical data.
> 2. The int[] value was written last.
> 3. The byte[] values were written last.
 
> Not terribly performant, but probably workable.  If C code could tolerate
> having "char" be 32 bits, that would simplify things a lot, but would of
> course break compatibility with a lot of code.

Java char is 16 bits, so you are halfway there.

-- glen

[toc] | [prev] | [next] | [standalone]

#72013

On Monday, October 5, 2015 at 5:18:52 PM UTC-5, glen herrmannsfeldt wrote:
> Java char is 16 bits, so you are halfway there.

That doesn't help if one wants to be compatible with code that expects C's
char type to be 8 bits, unless perhaps one decides to have code which
writes a "*char" perform a read-modify-write on an element of a "char[]" or
"short[]" while having operations on 32-bit types act on a pair of elements
in a "char[]" or "short[]".

It's too bad Java didn't provide functions to access individual pieces of
the longer primitives within an array.  I don't think there are any platforms
where that would have been expensive, and endian-ness issues could be resolved
by having separate big-endian and little-endian methods.  On a little-endian
machine, the little-endian method would read item "index" from a byte array
overlapped on the original, and a big-endian method would read item "index^3"
from that same array.  On a big-endian machine, simply swap which method
does what.

A function to copy one unaligned range of bytes to another would be cheaper
with one assumed endian-ness than the other, but not outrageously so.  The
JVM could almost certainly handle such things much more efficiently than can
user code written in Java without such a feature.

[toc] | [prev] | [next] | [standalone]

#72015

On 06/10/2015 00:16, supercat@casperkitty.com wrote:
> On Monday, October 5, 2015 at 5:18:52 PM UTC-5, glen herrmannsfeldt wrote:
>> Java char is 16 bits, so you are halfway there.
>
> That doesn't help if one wants to be compatible with code that expects C's
> char type to be 8 bits, unless perhaps one decides to have code which
> writes a "*char" perform a read-modify-write on an element of a "char[]" or
> "short[]" while having operations on 32-bit types act on a pair of elements
> in a "char[]" or "short[]".

Java's data types include signed 8, 16, 32 and 64-bit integers. And an 
unsigned 16-bit char.

Presumably the JVM supports these, and wouldn't be too hard for C to 
target. Harder are unsigned values (of 8, 32 and 64 bits).

Easier though to just use Java in that case.

Anyway, if the underlying software on smartphones is based around Linux, 
isn't that programmed in C? Then you'd use straight C. Although you 
might not then be able to operate within the Java environment.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#72033

Bartc <bc@freeuk.com> writes:

> On 06/10/2015 00:16, supercat@casperkitty.com wrote:
>> On Monday, October 5, 2015 at 5:18:52 PM UTC-5, glen herrmannsfeldt wrote:
>>> Java char is 16 bits, so you are halfway there.
>>
>> That doesn't help if one wants to be compatible with code that expects C's
>> char type to be 8 bits, unless perhaps one decides to have code which
>> writes a "*char" perform a read-modify-write on an element of a "char[]" or
>> "short[]" while having operations on 32-bit types act on a pair of elements
>> in a "char[]" or "short[]".
>
> Java's data types include signed 8, 16, 32 and 64-bit integers. And an
> unsigned 16-bit char.
>
> Presumably the JVM supports these, and wouldn't be too hard for C to
> target. Harder are unsigned values (of 8, 32 and 64 bits).

But it does not support pointers.  You would either have to model C's
address space as a giant array of bytes, or you would have to make all
objects into arrays of length one.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#72036

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

(snip)
>> Presumably the JVM supports these, and wouldn't be too hard for C to
>> target. Harder are unsigned values (of 8, 32 and 64 bits).
 
> But it does not support pointers.  You would either have to model C's
> address space as a giant array of bytes, or you would have to make all
> objects into arrays of length one.

Yes for scalars to look like C scalars, they have to be Java
arrays of length one.

I reasonably often use them in Java programs, for example to
put into a HashTable.

    ((int[])ht.get(key))[0]++;

-- glen

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web