flat assembler
Message board for the users of flat assembler.

Index > Heap > My machine has broken

Goto page Previous  1, 2, 3, 4
Author
Thread Post new topic Reply to topic
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
http://www.intel.com/design/processor/manuals/253667.pdf
chapter five, deals with VMX. I now have it. When will I read it?
Post 20 Jan 2008, 19:48
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
no tom, that is apparently different VMX:

Quote:
novel sorting algorithm for VMX instruction set of the PowerPC architecture


http://en.wikipedia.org/wiki/VMX
Post 20 Jan 2008, 20:08
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
System86



Joined: 15 Aug 2007
Posts: 77
System86
Quote:

Seems like these "false positives" on FASM package weren't such a "false" Smile
Have you tryed AV, anti-malware, anti-rootkit etc. software? Maybe you should update Win more often?


It's not a software problem Tomasz is having, it's a hardware problem. If it were a virus, even if it reflashed the BIOS the power supply would supply power and the fan would turn on. Anyway, I have fasm for DOS and Windows both on my system for a long time, and I haven't had any problems with it.
Post 20 Jan 2008, 21:33
View user's profile Send private message Reply with quote
FrozenKnight



Joined: 24 Jun 2005
Posts: 128
FrozenKnight
have you tried a different power supply if that doesn't then you will need to replace your MotherBoard. but from the sound of it your MB is most likely the problem. (anyone have 200-400 to donate.)
Post 27 Jan 2008, 22:06
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Check out VIA's upcoming "Isaiah". Very interesting read. Smile Might be a good choice for low-power cpu in the near future.

EDIT: Also see this: http://en.wikipedia.org/wiki/VIA_Isaiah
Post 27 Jan 2008, 22:27
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
I wonder if VIA are shooting themselves in the foot with Isaiah... they really should keep focus on small size and power consumption rather than performance.

Yeah okay, they're adding performance but staying low-power is a good goal... but it would be even better to stay at same performance, but going even lower power! - and focus on what the CPUs are interesting for, namely routers, storage (with AES encryption, thanks to padlock), not media centers...

But anyway, I've heard the chipsets for the VIA/C3 CPUs tend to be somewhat buggy. And the board+cpu is pretty damn expensive. Pretty interesting to see what's going on with Intel and their new simple low-power in-order execution CPUs...
Post 28 Jan 2008, 00:25
View user's profile Send private message Visit poster's website Reply with quote
farrier



Joined: 26 Aug 2004
Posts: 274
Location: North Central Mississippi
farrier
Check,

http://enthusiast.hardocp.com/article.html?art=MTQ1MCwxLCxoZW50aHVzaWFzdA==

Quote:
Without a doubt, what was most impressive was seeing a 1.8GHz CN processor running Crysis. While I am not going to go out of on a limb and say it was the best Crysis experience you might have, there is no doubt that this low power “UMPC” processor was more than up to the task that I would never ever guessed possible on a VIA/Centaur CPU. Certainly, CN is not aimed at powering the most demanding 3D shooter game in the world, and after seeing it run Crysis successfully it is certainly that the CN/Isaiah processor is more than up to the tasks that might be thrown its way in the UMPC segment.

_________________
Some Assembly Required
It's a good day to code!
U.S.Constitution; Bill of Rights; Amendment 1:
... the right of the people peaceably to assemble, ...
The code is dark, and full of errors!
Post 28 Jan 2008, 03:09
View user's profile Send private message Reply with quote
rugxulo



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

But anyway, I've heard the chipsets for the VIA/C3 CPUs tend to be somewhat buggy. And the board+cpu is pretty damn expensive. Pretty interesting to see what's going on with Intel and their new simple low-power in-order execution CPUs...


Well, hopefully the bugs are ironed out by now. Anyways, if you're worried about price, Intel isn't probably going to cut it either.

BTW, you obviously know much more than me, but from what I've read, in-order uses less power (but of course slower). However, most compilers these days assume at least Pentium (superscalar) or PPro (out-of-order) instead of 486 (pipelined), e.g. DJGPP now uses -mtune=pentium by default. But anyways, I've heard that Ubuntu (and Debian?) kernels are 486-compiled just because 1). anything higher makes little (if any) speed difference, and 2). on VIA chips (so far, previously only in-order) it works better (obviously, 486 only handles one instruction at a time ... do MSVC or Intel compilers even support 486 anymore??).

P.S. I haven't tested much, so my experience is low, but apparently GCC -march=i486 produces 386-compatible code but with more alignment, so it should still run on a 386. Kinda weird (and recompiling Bzip2 for my 486 via DJGPP didn't really speed it up much at all, so I was not too impressed). Even recompiling Info-Zip's ZIP and UNZIP via OpenWatcom "-4" didn't seem to help at all, speed-wise. (But that also still runs on a 386, as does e.g. "-6"). Oh well.
Post 28 Jan 2008, 20:31
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
If you look aside from stdlib and such, I believe MSVC should still produce code that works on 486 (hm, can't remember if I've ever made it use CMOV? - it seems to prefer arithmetic tricks instead.)

Out-of-order / speculative execution, I believe, is done to keep the various units inside the CPU busy, to utilize resources as best as possible; it does mean that it's a lot harder to optimize for the CPU though, since the CPU itself is optimize code on the fly, kinda.

For embedded-style CPUs, I think in-order execution makes sense (although with instruction pairing, to keep units busy), out-of-order adds a whole bunch of complexity. And research spent on OOO could instead be investigated into writing an optimizing target for GCC.

The whole linux kernel/system recompilation is pretty ho-humm. You don't get much advantage from, say, lots of specific compiler flags for your whole system (gentoo style), but that's to be expected - after all, you want the small% that runs [i]large[/b]% of the time optimized, not the UI code that isn't speed sensitive. And sensitive parts are bound to already either be written in assembly or use some pretty specific constructs.

Lots of the code affected is bound to be I/O limited anyway, whether it be by disk or other device speed. If you really wanted to speedup a linux system, you'd have to look for poor algorithm choices and bad protocol design first (considering how long time various X apps take to load, I wouldn't be surprised if symbol lookups are done using a linear search?)
Post 29 Jan 2008, 00:29
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
Well, just for the sake of example:

I compiled LPAQ1v2 with DJGPP 2.04 beta (G++ 4.2.2) yesterday twice, once via -O3 -march=i486, once via -O3 -march=pentium. A simple lpaq1 0 fasm.txt fasm.lp1 takes approx. 152 secs. on my 486 Sx/25. The 586 build only was different by 5 secs. On my P166 (no MMX), it was like 12 secs. (with 1 sec. difference to the 486-optimized .EXE). So, it doesn't help/hurt much by default (unless I guess you compress really big files).

N.B. Keep in mind that LPAQ is meant to be "lite", i.e. much faster than PAQ, so you can see how badly PAQ needs help. Wink

Granted, those times sound about right, and certainly I don't expect GCC to be perfect (or anywhere near it, actually), so obviously hand-tweaking would be suitable here (or at least doing suitable rearranging or profiling via C++ itself). However, I doubt even they understand all the intricacies of optimizing for cache, prefetch, alignment, slow vs. complex, pipelining, etc. At least, I surely don't have it down pat or anything!

Going over some of my hand-written asm, it seems most optimizations I find are due to redundant (or dead) code that isn't needed. And yes, some calculations could be done less (or only once, even) to speed it up. I tend to find more ways to save size than speed, however. And it is a little too tiny a difference unless you go through the critical routines, and even then it's hard to tell if it helps (even with RDTSC, I still wonder if it's worth it). But I persevere anyways because I know that stupid 486 is slow as dirt on things. Even the default UPX .EXE could probably be sped up if it was optimized more specifically for my cpus (instead of one-size-fits-all). Yes, compression and compilation times are where you really need to optimize, optimize, optimize!
Post 29 Jan 2008, 23:42
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

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

< 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 can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.