128 bit cpu's the sooner, the better.

Re-post, wanted electronics group in it as well but somehow wasn't added ;) :)

Bye, Skybuck.

Free Pascal already does 64 bit as does gcc. This means that if you write in Octave, your code can be written today as though it is running on a 64 bit array processor. When the cost of arrays comes down, your code will be ready.

You will see an improvement in overall performance but not as much as you may expect. Part of the problem is the carry logic gets slower for longer word lengths.

The ALU also takes up a lot more space. You could have two 32 bit ALUs in the space of one 64 bitter. If you go with a very long instruction word but only a 32 bit ALU width, you may see more improvement than going to a 64 bit ALU. Having code like:

Y[i] := Z[i] - Z[j]; i := i+1; j := j-1;

All end up as a single instruction can greatly speed up operation. It only requires one full ALU and the ability to increment, decrement and index via partial ALUs.

[....] 128 bit machines already exist. Doubling the word width one more time gets you far less than twice the performance. Algorithms can be fairly independant of CPU bus width. You can do 32 and 64 bit math on an 8051. [.....] 64 bit was supported fairly quickly by the industry leaders in software. It took longer for legacy softare to get replaced with wider word stuff. Having a 64 bit word doesn't help much when the code you run was all written in a version of Basic intended for 8 bit machines.

You're an idiot, SkyBuck Retarding.

You are an absolute Usenet retard.

Free Pascal does not do spaces in folders.

Renaming those folders could require as much as 40 hours of work.

Hours I rather spent coding.

GCC is even more retarded. It requires CygWin/Unix-like environment and takes ages to compile source files.

And then people wonder why I code in Delphi

How so ?

64 bit is an absolute requirement.

Try calculating Bill Gates interest rate on a 32 bit CPU then try it again on a 64 bit CPU and you'll see what I mean.

Something like, 2 procent:

(BillGatesMoney * 2) / 100

Easy with 64 bit instructions, difficult/hard with 32 bit instruction.

You'll need your own multiplication and division algorithms and those will take up many, many, many instructions and many iterations.

HUGE DIFFERENCE THERE.

Get a clue then come back ;)

I have seen many situations that require 64 bit by now, start paying attention ;)

Bye, Skybuck.

You're an idiot, SkyTard. You are an adolescent twit playing with a PC, and the extent of your knowledge rests very close to absolute nil.

You can install it into its own directory tree and avoid the problem with attempts to have spaces in the path to the *.exe files.

Free Pascal will let you do system calls. As a result, a program you write can do anything a C program can do.

You must be extremely slow at it. But obviously you don't need to do it.

gcc is certainly not retarded. You are trying to use a very advanced tool on an OS that sucks. gcc assumes that the standards are complied with. Windows is nonstandard in many ways. The cgywin places a wrapper over Windows to make it look standard to your programs.

gcc compiles quickly if you turn off optimizing. Even with optimizing off, it still constant folds. You can debug nonoptimized code much easier than optimized. Once you have the bugs out, then you compile it with the optimizer on and ideally use the "combine" feature to let it optimize across source files. The result can be as much as a 10 times increase in speed but the logic still works the same.

Answer this:

How many digits, at the most, do you need to consider to find out the top digit of the answer from an add?

How about I do it on an 8051? It is 8 bit.

/* Y and BillGatesMoney are both declared as 64 bit */ Y=(BillGatesMoney * 2) / 100;

****** Which compiles to: MOV DPTR,#BillGatesMoney MOV R0,#Work1 LCALL xLoadDbl MOV R0,#Work1 MOV R1,#Work1 LCALL AddDbl MOV DPTR,#ObviousFor100Dbl MOV R0,#Work6 LCALL cLoadDbl MOV R0,#Work1 MOV R6,#Work6 LCALL MulDbl MOV DPTR,#Y MOV R1,#Work1+8 lcall StoreDBL

The compiler does all the translation for you if you have a good one.

I don't need to write my own. They are already written and work just fine. A good C compiler comes with a library of such things.

No difference as seen from the source code level.

The same right back at you my friend. You are new to this stuff and haven't yet figured out how to do many very commonly done things.

No you haven't. You have seen situations where you can't figure out how to do the process without 64 bits. The weakness is yours not that of the machines.

[...]

There is no doubt that the Borland compiler is fast. It appears that Skybuck has noticed that finally.

Recursive decent parsers can lead to very fast compilers. This doubly true if you pass pointers to the strings not indexes and introduce a pseudo-atom for "go read more stuff". You can avoid the need to constantly check to see if you have hit the end of the source buffer and avoid the indexing computations. The scan process can really zip.

STAIRS.http://webpages.charter.net/jamie_5"

Those lcall's call routines.

Mind posting the instructions for those routines ? ;)

Once you look at those you'll start to understand how slow those really are.

Wake up and smelllll the coffeee :)

Bye, Skybuck.

it

,

em

om

t

..

)

Does anybody else here wonder what Skybuck does when he's not posting here?

I mean, he (she?) pops in here once about every 3 weeks with some inane horseshit that has nothing to do with SED. It's like some sort of weird circadian rythym....

-mpm

Does anybody else here wonder what Skybuck does when he's not posting here?

I mean, he (she?) pops in here once about every 3 weeks with some inane horseshit that has nothing to do with SED. It's like some sort of weird circadian rythym....

-mpm

NO DUMMY, YOU BOTH ARE ON CRACK!

--
Service to my evil master? Been there, Done that, and I've got my DD666 to
prove it.
Member of DAV #666.

Michael A. Terrell
Central Florida

YEAH FAST AND CUMBERSOME LIKE YOU SHIT EATER...Heeheee.....Donchaknow........

--
Service to my evil master? Been there, Done that, and I\'ve got my DD666 to
prove it.
Member of DAV #666.

Michael A. Terrell
Central Florida

If you are going to forge, please take a second to think about who you are going to make look bad when you do that bad of a job of it.

You be they do.

How much will you pay me.

I've done far more than look at such libraries. I've written them. They do exactly the thing you said they couldn't.

I'm on my second cup.

Shut up GoofFAT, I am being obvious in order for a retard like you to distinguish. What you dumbass have to do is to use your brain, ask yourself What did you do to yourself to begin with.

--
Service to my evil master? Been there, Done that, and I\'ve got my DD666 to
prove it.
Member of DAV #666.

Michael A. Terrell
Central Florida

Look at the DumbFuck MooseFAT, his mistake is no different, and he tried to be picky with others...Heeheee.....Donchaknow........

--
Service to my evil master? Been there, Done that, and I\'ve got my DD666 to
prove it.
Member of DAV #666.

Michael A. Terrell
Central Florida

bit

rt,

r

stem

r

from

est

t...

l

;)

It seems likely to me that he is a student somewhere or something like that. He has been posting here long enough that I'd expect him to graduate some day soon.

I really don't understand these personal attacks. Oh well, I know enough cuss words. I think I'll look for a thread where I can learn something new in design. ;-)

I never said they couldn't.

I said they be slow.

I need something fast.

I need true 64 bit instructions from the processor.

128 bit instructions could be very interesting as well, for the future and for now too.

For example memory copy/move routines could be optimized to copy/move 128 bits per instruction.

Sounds nice because: those copy routines are used a lot you know ! For example Delphi strings use them lots and lots and lots I am pretty sure about that ;) :) "copy-on-write" and all that ;)

Bye, Skybuck.