flat assembler
Message board for the users of flat assembler.

Index > High Level Languages > Human vs. compiler

Goto page Previous  1, 2, 3  Next
Author
Thread Post new topic Reply to topic
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Futuristic Barny (borg): I am you, you are me, we're co-lec-tive ent-ti-ties.

I'm sick of the HLL propoganda, though. They can go ahead and have their slow, imperfect coding language that also makes it harder to learn how to make your code faster (such as using a while instead of a for in C++ if you're doing a count that you can impliment to stop at 0). I'm just sick of them making us look like obcessed people with no life.
Post 21 Dec 2006, 03:53
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
HLL propaganda? *shrug*

Most HLL coders I know chose their language of choice because it gets the job done faster than <insert other language>, or because there's some other advantage to it.

If you write code that needs to run on both 32- and 64-bit x86, assembly is already not the best choice. Once that code also needs to run on Itanium, PA-RISC, ARM/XSCALE, etc... then you don't really want to do it in assembly Smile

For code that revolves around API calls (like most GUI stuff), you don't need assembly either - even a shitty compiler like PowerBASIC will not generate bad enough code that you can time problems.

How long have you been programming? Which languages, and for how long? Your previous post where you obsessed about irrelevant details, it would seem that you haven't used neither assembly nor a HLL for very long...

If you had, you'd probably also know that compilers can "turn a for loop into a while loop", and you'd know that not everybody writes retarded code Wink
Post 21 Dec 2006, 23:12
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
I've used C++ for about 2 years now. i'm still learning assembly. As for turning a for into a while... let's take teh following code...

Code:
for (int count=0; count!=100; count++)
  answer+=count;    


The compiler dosn't know to turn that same code into the following...

Code:
int count=100;
while(count){
answer+=count;
count--; }    


Now i don't know for sure (i admit) that the latter one wouldn't need the sub or something to check if the condition is false or not.
Post 22 Dec 2006, 03:05
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Compilers, while some are pretty good, still aren't perfect. You're right with this pretty contrieved example - MSVC fails to do this particular reordering here, it probably doesn't like the counter dependancy.

I've seen it done for other (real world Wink ) pieces of code, though. And oftens this either
A) won't matter
B) matters to the extremes, where you're better off doing assembly anyway Wink
Post 22 Dec 2006, 03:44
View user's profile Send private message Visit poster's website Reply with quote
Goplat



Joined: 15 Sep 2006
Posts: 181
Goplat
Kohlrak: Those are not equivalent - the first sums 0 to 99, the second sums 1 to 100.
Post 22 Dec 2006, 07:17
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
lol, good eye goplat.

and the problem, fodder, is that we don't know how well the STL and things are coded to begin with. Too many people don't know about the "inline" keyword in C++, and i often forget it myself. And maybe it dosn't matter, and sometimes it does. In my personal opinion, if you pay for something it should be the best you can make it. So you have a large number of corperations using C++, and them all codding not only horribly, but using an impefect compiler, and with habits like theirs, they really could use every clock cycle that they can get. Especially if you're making a game and would like to clock about 60 FPS. Problem is that people aren't taught all the "nifty little tricks" of their nice HLLs, and to top it off the compiler isn't smart enough (and it shouldn't have to be) to make their algorithams better. In assembly you can get a pretty good idea just by looking at your code weather it'll be fast or slow. These HLLs, on the other hand, are a bit far from what the code actually looks like. People often like to beleive that since the compiler has "optimization features" that it'll be able to understand their program and do all the problem solving for them. One of the students in my C++ class in school claims microsoft made an A.I. program. Now i know many people like to make this claim with their software, but there is no such thing as artificial intellegence. It's either intellegent or it's not. Too many people don't know diddly squat about their computer.
Post 22 Dec 2006, 08:20
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
In my personal opinion, if you pay for something it should be the best you can make it.

In "real" (bussiness capitalistic sales management driven) world it's more like: "We can make it cheapiest and crappiest possible, if we can get paid for it"
Post 22 Dec 2006, 09:50
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Raedwulf



Joined: 13 Jul 2005
Posts: 375
Location: United Kingdom
Raedwulf
vid wrote:
Quote:
In my personal opinion, if you pay for something it should be the best you can make it.

In "real" (bussiness capitalistic sales management driven) world it's more like: "We can make it cheapiest and crappiest possible, if we can get paid for it"


Yes unfortunately thats true...
That is why even just general products are not built to last these days e.g.
my dad's old 17" Philips monitor bought way back 1994 lasted till two months ago. and what TFT monitors have a life expectancy of 3 years?

Cheers.

_________________
Raedwulf
Post 22 Dec 2006, 11:31
View user's profile Send private message MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
kohlrak wrote:

and the problem, fodder, is that we don't know how well the STL and things are coded to begin with.

You use the STL to get the job done. If you end up with a speed or (memory) size bottlenecks, you research the problem, and possibly write your own algorithm/container/etc. STL implementations are generally pretty decent these days, but you can do better when you really need it; for instance I probably wouldn't use STL for the inner parts of a raytracer.

kohlrak wrote:

Too many people don't know about the "inline" keyword in C++, and i often forget it myself.

Most compilers ignore the "inline" keyword, so it's more a question of knowing where to put your functions. For very short ones that need inlining, they need to go in a header file. "Link-Time Code Generation" helps this somewhat, but it's still a good idea to keep the really short functions in headers.

And of course to think long and hard about program/class design, so you don't have too many necessary really-short functions.

kohlrak wrote:

Especially if you're making a game and would like to clock about 60 FPS.

You're not really CPU bound in games these days, you're largely GPU bound. Things like physics and AI is mainly what's done on the CPU, and those are relatively complex tasks - I dunno how much benefit you'd get from assembly-optimizing that, really.

You might want to check google, to see that even for GPU-bound games, optimizations are being done.

Now, if you look at the standard assembly code being churned out by people, lots of it is of pretty poor quality. See just about anything created by a MASM32 user, and the M32LIB in particular.

vid wrote:

In "real" (bussiness capitalistic sales management driven) world it's more like: "We can make it cheapiest and crappiest possible, if we can get paid for it"

Wrong - "crappiest" is not part of the equation. It's "We'll ship it as fast and cheap as possible". Depending on company, this can mean crappy software... on the other hand, there's still companies that try to "get things right" - I think Blizzard has done pretty well.
Post 22 Dec 2006, 11:56
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
Now, if you look at the standard assembly code being churned out by people, lots of it is of pretty poor quality. See just about anything created by a MASM32 user, and the M32LIB in particular.

you are unfortunately right about this. One of problems is for example, that new people are given bad practice. Almost no asm coder checks return values, etc. I am even pushing on tomasz now to add error handling to all examples Smile

about the companies: i know only very little software that didn't bitch up with managementy things. And i don't know ANY new company which takes quality into account.
Post 22 Dec 2006, 12:49
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
Most compilers ignore the "inline" keyword, so it's more a question of knowing where to put your functions. For very short ones that need inlining, they need to go in a header file. "Link-Time Code Generation" helps this somewhat, but it's still a good idea to keep the really short functions in headers.

And of course to think long and hard about program/class design, so you don't have too many necessary really-short functions.


I have a simple rule... If it is used once, it dosn't go into a function. On the flip side, people are usually told to put big sections of code into functions, even if it's only used once. So the flip side needs to learn how to use the inline, if they're going to do that, so that the code will be at least a bit faster.

Quote:
You're not really CPU bound in games these days, you're largely GPU bound. Things like physics and AI is mainly what's done on the CPU, and those are relatively complex tasks - I dunno how much benefit you'd get from assembly-optimizing that, really.


Well, first off, since they depend on each other you'll want to make whatever code that the GPU must execute (such as the algorithams to decode the models or images) you'll want to make that as small as you can (because from what i've heard, the GPU runs a bit slower than the regular processor) and even a slow calculation on the AI can be pretty laggy if you have a complex enough AI, and now people are getting more and more concerned with how "smart" their "ai" are.

Quote:
You might want to check google, to see that even for GPU-bound games, optimizations are being done.


Just enough to give the company a good outlook so the product sells. Let's not forget what some people THINK are optimizations, but really the opposit.

Quote:
Now, if you look at the standard assembly code being churned out by people, lots of it is of pretty poor quality. See just about anything created by a MASM32 user, and the M32LIB in particular.


Just looking at the quality of the popular C++ classes, i could just imagin how poor the assembly information can be, since it is hard to get, we really can't get very picky with what we ask for. I find it alot easier to optimize in assembly than C++. When i think of the best way to do the calculations, i usually miss alot.

Quote:
Wrong - "crappiest" is not part of the equation. It's "We'll ship it as fast and cheap as possible". Depending on company, this can mean crappy software... on the other hand, there's still companies that try to "get things right" - I think Blizzard has done pretty well.


Keyword bolded and underlined, and even then. How hard are they trying?

Quote:
you are unfortunately right about this. One of problems is for example, that new people are given bad practice. Almost no asm coder checks return values, etc. I am even pushing on tomasz now to add error handling to all examples


Windows programmers are supposed to "program on the defencive." Whatever happened to that logic when making an API? I never made a DLL in assembly, but you better beleive that if i did i'd make sure that some sort of predictable return value was sent, weather it be an example of windows' troolean logic to tell if there were any problems or not. There's no excuse not to do this. Personally, i think that coders making things should also be a little more considerate about conservation of the registers. For instance, if you don't have a creative use for what you put in the registers other than eax, perhaps you should consider putting a warning, at least, that those registers are going to be edited.

Quote:
about the companies: i know only very little software that didn't bitch up with managementy things. And i don't know ANY new company which takes quality into account.


Isn't that the truth... lol Sit in my computer class and you'd understand why. I try to make a habit of making my code as optimized as possible, even if i'll never use the program more than once. That way optimization becomes a habit and i can honestly say that all my programs are efficient. Yet, in my C++ class, we're not allowed to use things that we havn't covered yet, that includes things we'll never cover. Now, i could easily use alot of the binary operators to enhance the execution time very, very greatly. And these people will make a habit of NOT using them, because of this. Yea, his reasons are noble for saying some of the stuff we can't use until we've covered it, but stuff that we won't cover we should be able to use. I've noticed the bad habits are really rubbing off onto my C++ programs, and it's becomming hard to make my C++ programs as efficient as they were before i started taking the class. The problem is nobody knows what they're doing or talking about anymore, and, i'm sure by now you know this, that it's pretty bad when I am pointing that out.
Post 22 Dec 2006, 18:58
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo

  1. if your main objective is only to make money, your compiler probably won't be as good as the one whose goal is to run fastest and produce smallest/fastest code, etc.
  2. am I wrong or wouldn't the ideal be that HLL compilers were themselves written in assembly? (self hosting compilers are cool but impractical in some ways)
  3. some things aren't meant to last (e.g., 12-year-old tv's) ... you'd probably want to upgrade anyways (or maybe not if you're really cheap bastard like me Laughing)
  4. I heard once that the human eye can't even detect FPS above a certain number (20??) ... besides, I think 60 FPS is unreasonable, many games are playable with only half that (or less!)
  5. we all write in whatever language using whatever assembler/compiler because it's fun, right? besides, optimization can be enjoyable too (yay, I squeezed 10% off my .EXE!)
Post 23 Dec 2006, 15:06
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
if your main objective is only to make money, your compiler probably won't be as good as the one whose goal is to run fastest and produce smallest/fastest code, etc.


That's why it's so sad how the best compilers are the free ones where the gain is honor rather than money.

Quote:
am I wrong or wouldn't the ideal be that HLL compilers were themselves written in assembly? (self hosting compilers are cool but impractical in some ways)


I've seen one written in.. i think it was called delphie or something...

Quote:
some things aren't meant to last (e.g., 12-year-old tv's) ... you'd probably want to upgrade anyways (or maybe not if you're really cheap bastard like me )


I don't know about this floormodel here. I think this one's older than me.. lol It's at least 15 years old. This is one rugged tv.

Quote:
I heard once that the human eye can't even detect FPS above a certain number (20??) ... besides, I think 60 FPS is unreasonable, many games are playable with only half that (or less!)


I think it has something more to do with how fast they move on the screen rather than the actual frames that are done. I'm not sure though, i've never gotten that far into graphics development cause i never found a tutorial simple enough. But by the time your comp gets slowed down to 20, your music is noticibly slower. Perhaps the need for 60 has something to with lack of ability to code your own, and decent, sycronization scheme.

Quote:
we all write in whatever language using whatever assembler/compiler because it's fun, right? besides, optimization can be enjoyable too (yay, I squeezed 10% off my .EXE!)


true, and you can do all of that, but i hate how companies do that. Plus, if you saw my taskbar you'd understand why i'm so criticle of speed handy applications. lol Trust me, it's scary.
Post 23 Dec 2006, 15:20
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
[quote=kohlrak]
I have a simple rule... If it is used once, it dosn't go into a function. On the flip side, people are usually told to put big sections of code into functions, even if it's only used once. So the flip side needs to learn how to use the inline, if they're going to do that, so that the code will be at least a bit faster.
[/quote]
If you're only calling it once, there's (usually) no reason to inline it, speedwise. And it's much easier to read a bunch of small functions than a single monolithic one (try looking at projects not written by yourself).

[quote=kohlrak]
Well, first off, since they depend on each other you'll want to make whatever code that the GPU must execute (such as the algorithams to decode the models or images) you'll want to make that as small as you can (because from what i've heard, the GPU runs a bit slower than the regular processor) and even a slow calculation on the AI can be pretty laggy if you have a complex enough AI, and now people are getting more and more concerned with how "smart" their "ai" are.
[/quote]
GPUs have have lower clock frequencies than CPUs, but they're extremely fast at what they do - relatively specialized functions. (Funny thing is that those operations aren't just graphics limited, and with the GF8800 and later generic programmable versions, we're going to see interesting stuff).

[quote=kohlrak]
Just enough to give the company a good outlook so the product sells. Let's not forget what some people THINK are optimizations, but really the opposit.
[/quote]
Heh. Again, check quake3 - there's some pretty nizzle stuff there, programmer pride, not just "selling the game". And as for "THINK are optimizations", remember your nit-picking about calling conventions Wink

[quote=kohlrak]
Just looking at the quality of the popular C++ classes, i could just imagin how poor the assembly information can be, since it is hard to get, we really can't get very picky with what we ask for. I find it alot easier to optimize in assembly than C++. When i think of the best way to do the calculations, i usually miss alot.
[/quote]
You're bitching about code quality, and at the same time saying "we'll have to use what we can get" - that doesn't compute. Also, considering how much C and C++ code there's around, a lot of it sucks - but have a look at things like the MACH kernel, and code from the *BSD projects - that's generally pretty high quality code.

Dunno if it's easier to optimize in assembly, but it's certainly where you can gain the largest optimizations.

[quote=kohlrak]
Keyword bolded and underlined, and even then. How hard are they trying?
[/quote]
Hard enough that they actually produce quality Smile

[quote=kohlrak]
Windows programmers are supposed to "program on the defencive." Whatever happened to that logic when making an API? I never made a DLL in assembly, but you better beleive that if i did i'd make sure that some sort of predictable return value was sent, weather it be an example of windows' troolean logic to tell if there were any problems or not. There's no excuse not to do this. Personally, i think that coders making things should also be a little more considerate about conservation of the registers. For instance, if you don't have a creative use for what you put in the registers other than eax, perhaps you should consider putting a warning, at least, that those registers are going to be edited.
[/quote]
Not all of the Windows API is well designed - especially not things like the "common controls" introduced with IE. But return values are necessary... unless you want to introduce something like 'errno'.

Registers, ho humm. The existing calling conventions makes a lot of sense, actually - scratch and persistance. If it wasn't done this way, either functions would be free to trash all registers (and caller would have to preserve everything, often a waste of time), functions would have to preserve all registers (not really needed, again a waste of time), or you'd have per-function specification (a horrible mess).

Also do keep in mind that any wide-spread OS is written "for the masses", so it's written in C...

[quote=kohlrak]
Yet, in my C++ class, we're not allowed to use things that we havn't covered yet, that includes things we'll never cover.
[/quote]
It makes sense having to cover the basics before you move on, and be limited to the basics so you learn them well - not everybody knows a lot when they take a computer class. Sucks if there's important topics you won't cover, and from other posts you've written it sounds like your class sucks. Things aren't like that everywhere though. I can only speak from what I know from Denmark, where the quality is generally very high.

[quote=kohlrak]
Now, i could easily use alot of the binary operators to enhance the execution time very, very greatly.
[/quote]
Where would you use this to enhance execution time so much? It sounds like you're doing a lot of useless micro-optimizations that you don't get much benefit from, instead of writing clear code and doing optimizations where they matter.

[quote=rugxulo]
I heard once that the human eye can't even detect FPS above a certain number (20??) ... besides, I think 60 FPS is unreasonable, many games are playable with only half that (or less!)
[/quote]
The cited fps rate is 24 - but I've never seen a reliable source. And there's certainly a difference in smoothness in games from 24 to 65fps, but that is also related to animation smoothness etc. But then there's 60 vs 85 (or higher) refresh rates for CRT monitors - that's very noticable too... so I think the 24fps figure is wrong.
Post 23 Dec 2006, 17:53
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Quote:
That's why it's so sad how the best compilers are the free ones where the gain is honor rather than money.

Nothing sad about that. Good is good, free or otherwise. Besides, if the best is free, woohoo! Can't complain. Wink

(BTW, what C++ compiler is the best? I assume GCC, but some would probably say MSVC.)

Quote:
Also, considering how much C and C++ code there's around, a lot of it sucks

I think C being free form makes it much MUCH easier to write ugly code. IOCCC was actually inspired by a sh clone or whatever. Plus, there are just too many C/C++ compilers (although I actually like that ... fun!) and standards (ANSI, DOS, Win, *nix, C99, POSIX, K&R, etc.). That's just my opinion, though. (Maybe if I didn't suck at C, but it's just such a seemingly HUGE language with a billion quirks ... argh).

Quote:
Also do keep in mind that any wide-spread OS is written "for the masses", so it's written in C...

OS/2 had a kernel written in assembly (supposedly), and that was popular. Face it, writing portable HLL (e.g., C) code is cool and all, but it isn't always the best idea. Your replies always seem a bit biased (in a good way, I guess) based on your experience. Your opinion is always valuable to me, though. Wink

Quote:
I can only speak from what I know from Denmark, where the quality is generally very high.

They don't force you guys to learn C++ just because BS is from there, do they? Laughing
Post 23 Dec 2006, 18:52
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
rugxulo wrote:

(BTW, what C++ compiler is the best? I assume GCC, but some would probably say MSVC.)

"Depends" Smile

For x86, MSVC (2003 or newer, '98 is really outdated and 2001 has bugs) and Intel's compilers are very good. GCC 3.x usually lags behind, and I haven't bothered to play with GCC4 yet (supposedly finally introduced some optimizations VC has had for years which help a lot), but there isn't an official mingw port of it yet, and I've heard that some linux apps break with V4 - although that's probably more a fault of the app than GCC Smile

rugxulo wrote:

I think C being free form makes it much MUCH easier to write ugly code.

You can write REALLY ugly code in C/C++, and some do this. Shame on them. On the other hand it's also possible to write pretty clean, lean and nice code. Just like it's possible to write commented and fairly readable assembly Smile

rugxulo wrote:

and standards (ANSI, DOS, Win, *nix, C99, POSIX, K&R, etc.)

If you stick to ANSI, you can get your code working most places. I hope I'll never have to write for pre-ANSI platforms, as that's IMHO broken. I prefer ISO C++, but ANSI C will do. Lots of your core stuff can be written in clean and portable ANSI or ISO, and then the OS-specific interfacing done with POSIX, WIN32, whatever.

No, you don't get much done from 100% portable code (at least without some portable framework Smile ), but the OS glue doesn't necessarily have to be too thick (you could write, say, a portable torrent client with a portable core, and OS glue for NT IOCP, linux /dev/epoll, BSD /dev/kqueue - if you need an UI, that'd take some more Smile ). And if you don't mind frameworks, well, there's a lot of them around for various stuff.

rugxulo wrote:

OS/2 had a kernel written in assembly (supposedly), and that was popular.

I somehow doubt it was assembly - although, given the period it was written in, it could have sizable assembly parts. Haven't ever played with OS/2 though, so couldn't tell Sad. But, around here, it was only die-hard fans that used OS/2, after MS backstabbed IBM and did NT.

rugxulo wrote:

Face it, writing portable HLL (e.g., C) code is cool and all, but it isn't always the best idea.

Indeed.

Especially things like the critical parts of real-time OSes.

rugxulo wrote:

Your replies always seem a bit biased (in a good way, I guess) based on your experience.

I'd be a hypocritical liar if I claimed I wasn't biased Smile

Funny thing is I can recognize "the younger me" in a lot of current die-hard assembly users. Heck, I think there's even a document I wrote as late as ~2000 that says something similar to "WRITE MOST OF OS KERNEL IN ASM!!!". Since then I've gained more experience and compilers have become better... Smile

Computers have become faster as well, but I still keep old hardware around for testing... I usually don't need to resort to assembly to get decent speed, though - the trick is to write non-retarded code, and think about data structures and algorithms (and be lazy and use STL or whatever when it doesn't matter ^_^).

But then again do keep in mind that I don't really do sound or graphics programming. If I did, I'd probably do assembly more than I do those days. If for nothing else, because it's fun Smile


rugxulo wrote:

They don't force you guys to learn C++ just because BS is from there, do they?

*grin*

Nah, more like because it's probably the most widespread language that has plenty of grunt. I think most of the comp.sci. courses start with JAVA though, but then progress through a wide range of language of various classes. The comp.eng. course I'm going to attend next year focuses more on C++ and pure C, JAVA isn't good for all embedded devices. It's okay on phones, but I wouldn't like the idea of it on anything critical - not even with one of those "JAVA CPUs".
Post 24 Dec 2006, 20:58
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Friend experienced in area told me that java for mobile phones is completely unportable. There is no standard interface for accessing those devices.
Post 24 Dec 2006, 23:04
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Wouldn't surprise me - you can probably do some fairly trivial stuff portably, though (the j2ee or whatever subset) - and it shouldn't be too hard targetting multiple devices.

But sorta sucks having to recompile when the idea of java is "bytecode that runs everywhere" Wink. Heck, some games written for a K500i won't even run on a K750i - how sucky is that?
Post 25 Dec 2006, 01:49
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Here's a practically full-speed GPL Sinclair Zx Spectrum 48k emulator for the Sony Ericsson P900 phone written almost entirely in C++ using Linux. (Haven't tried it, don't have a P900, but just FYI). Smile
Post 25 Dec 2006, 02:52
View user's profile Send private message Visit poster's website Reply with quote
Filter



Joined: 08 Oct 2006
Posts: 67
Filter
Maverick wrote:
kohlrak wrote:
The computer can't always beat the human, but the human can always beat the computer.

Sure, expecially MIPS wise. Wink

In 50 years we'll be useless, and assimilated or replaced. Very Happy


Maverick, we will do rom dumps of our brain and run ourselves emulated on the fasted multi-core light processors ever designed.
Post 25 Dec 2006, 04:13
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.