[ Post removed by author. ]

In the movie Kill Bill 2 Uma was buried alive. That was an awesome scene. Fortunately I wasn't being burned alive at the time I was watching it.

Hehe, I misread that so badly. burned <> buried. Perhaps my font is too small?

[ Post removed by author. ]

That makes a much better argument than the one by HaHaAnonymus.

Relax. I'm not trying to threaten you.

My view is that the PC cum BC ( Business computer ) created a mass market that won out because of the pending globalization of commodity device-ing, back in it's day. So as it's volume drove Moore's curve they only thing we humans could utilize their ever increasing capabilities for was the meta stuff, culminating in DB back-ends now serving the dissection of our online activities for BC usage, the serving of the vast BC enterprises on the web and the clouding of the resulting participation.

The new wave of personal; devices, from mp3 thru merged phone browser/player and enhanced version in tablets is indeed powered by micro-controllers vs. microprocessors.

So to tack it down I see the device vs pc divide being managed by BYOD management by BC protagonist and possibly enhanced with DYI pseudo device oriented mash-up like customizations that users can control.

As the micro-controllers allocate more resources to support BC OS's you will see people like us bending it to the will expressed here.

Cheers, Feedback welcome, Clyde

I look forward to simpler micro-controllers for those who want to mash-up their own IOT's.

i dont understand clearly above. the meta-stuff, the only end-user
can control/customize, may drive pc business to discontinue the Moore's law.
it will not be anyways thru ARM,imho: because ARM is low power and rather industrial
than home. or say, we have a 20 watt hardware to allow more resources on larger-skala.
the Win8 porting to ARM is an example. it seems a failure. or we must wait
for the "activation" of the meta-stuff thru it, according this logic:

more meta-stuff-awareness -> more resources available -> better/stable-markt hardware => fasmarm worth to be 3xARM.

the question is always there, as hinted by revolution. i quote it again:


and... editing...

if meta-stuff matters, why PlayStation4 mounts AMD on it ?

yeap, true, true,true. what should i say ?
from october, 2012, browse the chart there
http://www.theregister.co.uk/2012/10/10/multiplatform_linux_kernel/

Cheers,

Indeed. Still no good dev system. All the systems currently around (and there are many) are all different from each other and have different setups and configurations. I don't see this being fixed any time soon. And worse is that many of the systems like to "protect the user from harm" and lock everything down tightly.

IMHO there is no need to port FASMARM to ARM. I think you can easily run
FASM from Wine under Linux ARM, as for performance issues there should be
none, as FASM is a light weight application.

Yes, I am that guy so long as the device is running a POSIX system, conforms to the the ARM EABI and has enough resources for the job (a RW filesystem with enough space for the tools, etc).

I totally want to adb into my rooted Android phone to compile and debug small linux applications. (This is not normal.) I am really interested in doing this on FreeBSD for ARM, but I am making do with my phone for now. I suspect most people want to use Raspbian (Posix+EABI compliant, note the float passing conventions).


As of now I am compiling remotely and debugging with gdb by targeting the remote binary. I am doing this because I have no choice in the matter. For large applications remote compilation is ideal. If suitable development hardware is available, I feel local compilation is generally ideal for toy programs.

its already running with emulation and you can run and debug the binary file
http://s17.postimg.org/9s1s9353j/Screenshot.png

here are the steps with ubuntu:



and for execution:

(of course its the elf binary)
have fun!

If your ARM board runs Linux then you can emulate. But not everyone runs Linux, or even any OS.

Since speed is probably not an issue with an assembler then I expect emulation should be fine. Unless you have some weird usage that requires the assembler to run 24/7?