64-bit PB Compiler

[Haitham Yousef]

Hello Everyone,

I am not a compiler specialist and would like to know, in simple terms, what is needed to create a 64-bit PB compiler? I know that 64-bit Windows is needed.

[Mel Bishop]

Well, it's pretty much common knowledge that PB is written in assembly. I suppose a 64-bit assembler would come in handy.

[Michael Mattias]

It will also take the same minumum requirement for creating a 16-bit or a 32-bit compiler: a lot of expertise and experience.

[Haitham Yousef]

So, loading 32-bit assembler code into a 64-bit assembler and compiling it would do the job or you will need to hand tune the code and add 64-bit specific instructions to maximize the performance?

[Michael Mattias]

Do you want a compiler, or are you trying to create a 64-bit executable from a 32-bit execuatble by dumping the disassembled code and re-assembling?

If the latter, you don't "have to" optimize instructions for 64 bits, but it would be totally and absolutely silly to create a 64-bit application which wasn't optimized for the CPU, unless you have a 64-bit OS which won't run a 32-bit application. In which case you would be running something unsupported by PowerBASIC, and quite possibly would be in violation of your compiler license since you would be using the proprietary runtime routines in something not compiled with a licensed compiler product.

[Guy Dombrowski]

64 bits compiler ?

After upgrading from my former 16 bits compiler to PBCC 32 bits, I will not live long enough to use 100% of my new tool.
And with new computers getting faster all the time, is there a need for such a complex new software any time soon ????

[John Petty]

Haitham
Simple answer is a lot of work so some simple explanations, hopefully reasonably accurate.
First history, Intel produced a 64 Bit chip/system which was basically not backward compatable with any existing software. AMD discovered one bit in one flag of one instruction that allowed that allowed the switching of the CPU from 32 Bit mode to 64 Bit mode and vice versa so Intel gave in.
Once you switch everything changes, ie address registers become 64 bit not 32 bit etc, in fact it can use a whole new different instruction set though from what little experience I have they have kept it as close to the old as possible while adding great features like big endian storage.
The changes are of such a magnitude that for most common software to take advantage of the increased power will take major rewrites.
Personally I think it is the way of the future but will be much slower than the transition from 16 to 32 BIT
John

[Michael Mattias]

And with new computers getting faster all the time, is there a need for such a complex new software any time soon ????

Probably not.

However, I have said many times before and I'm stickin' to my story: the vast majority of performance problems are caused by poor design and/or programming technique, and neither faster computers nor enhanced compilers are going to solve those problems, ever.

MCM

[John Petty]

Obviously bad programmers can slow things down but even "good" programmers like Michael rely on tools like data bases for their programs performance (and even then a bad programmer can make them run slow) without knowing how they get the performance.
Going to from 32 to 64 bit by itself is a case of diminishing returns but this time it is a little different so a little history. My personal opinion is that IBM's choice of the Intel 8088 for the PC delayed high speed personal programming by 5 to 10 years. I had a 16 bit micro running in I think 1976 and a 16bit bus 24Bit addressing 32 bit internal in 1979 (equivalent to an intel 386). I had beta chips of a full 32 bit linear addressing virtual page mode etc in 1983 (better than an Intel 486 or early pentium). The Motorola 68000 I think also came out in 1979. All these CPU's had, apart from being more advanced than Intel, a major difference, they were Big Endian. There were good reasons why Apple chose the 68000 and math intensive graphic programs like Adobe's range (photoshop etc) and Quarck chose Mac's for their platform.
Many years ago I posted time comparisons just emulating Big Endian for big sorts of strings and more importantly mixed fields of UDT's (say a long + a fixed length string + a double) which were typically 60% faster than PB's very fast sorts.
So the current improvement in CPU design creates a difficult problem. To gain the maximum benefits (particularly for data bases) it requires loads of code to be able to have any backward compatability.

[Guy Dombrowski]

Data Bases

I have been building my own Data Bases even before the 8088 time and I still do. Think Motorola 6800 in 1977.
The main benefit, apart from full control and security, are incredible speed with the new hardware and small footprint.

[Haitham Yousef]

Thank you all for your feedback.

The reason for asking the question about 64-bit PB compiler and what would be involved in switching to 64-bit was that in the not too distant future Windows will be 64-bit only, Windows 7 will be the last 32/64-bit OS which means by 2013/2014 64-bit Windows will be the only option from Microsoft for the masses. For the sake of backward compatibility 32-bit code will run on 64-bit windows but for how long. Add to that 64-bit programs are running faster than their 32-bit counterparts if a good programmer is doing the job.

[Haitham Yousef]

John,

Could you please explain why 8088 delayed high speed computing by 10-15 years? I used to have a PC in 1988 which ran on a 10MHz 8088.

[Kev Peel]

Windows 7 will be the last 32/64-bit OS

Would need a source to believe this fact. Even if it were true, 32-bit software support will probably never be dropped.
Remember, you can still run 16-bit apps, even on a 64-bit system with the correct emulation tools (VMs, etc).

[John Petty]

Haitham
CPU design can be more important than clock speed (actually I said 5 to 10 years) some are simple things like number and size of available registers.
Probably the two most important factors I can remember are first that it was Little Endian, so let me explain that. In English (and most other languages) if want to write a number say 1500 the big order digits come first, on Intel 88/86 computers it is 0051. This means that when the CPU loads the number into say a 32 bit register that the low order byte number is loaded into the high order 8 bits of the register the second byte into the second highest 8 bits etc ie the 4 bytes are reversed, not serious for math. Now consider what happens with strings (characters). If we have a 32 bit bus so can load 4 characters at a time to our 32 bit register we can only compare them for = but not > or < as the 4 characters are reversed, so to properly compare strings we have to load and compare 1 byte at a time so losing all the speed advantage of going from 8 to 16 to 32 to 64 bit processing. The situation gets much worse if you are trying to compare UDT's say a 7 byte string followed by a long then your program would need first compare the 7 byte string 1 byte at a time then know the next 4 bytes were a long and compare them 4 at a time. The UDT I just described has 11 bytes, in Big Endian with 32 bit registers you would merely compare the first 8 bytes 4 at a time and for the last 3 load 4 but shift right 8 bits before comparing. Much simpler and miles faster.
The second problem was it did not have linear addressing. Competing CPU's before IBM chose the Intel 8088 (because it was a major shareholder) had 24 bit (1 MB) linear addressing, the 8088 used an outdated concept of segment registers so you could only quickly address within a 64KB range (16 bits), else you had to first set up the segment register (with your program always having to remember what segment it was currently addressing) and then locate the byte or variable you were trying to locate, very slow and complex, many instructions having "near" and "far" versions to handle it. Linear addressing CPU's automatically scaled up as bus width increased, segmented programming didn't. Intel overcame this with the 8386 which allowed windows 32 OS's to be introduced (partly with 95) and was the biggest factor in the speed gains achieved by their 32 bit OS's. Come to think of it that is 15 years after the introduction of the (IBM derived) PC.
John

[Haitham Yousef]

Thanks John for your reply. I would like to add that Microsoft was very late to introduce a 32-bit OS. If they only released a 32-bit DOS in 1986 when Intel released the 80386 processor then later on introduced a GUI layer to it (like X11) and after that a full blown 32-bit Windows. Imagine having a true 32 bit Windows in time for 80486 or the first Pentiums (60 & 66MHz). Where will we be now? At least we would not have had the 16/32 bit hybrid Frankenstien OSs i.e. Win98/98se/Me.

Some one once told me that Win98/98se/Me are 'mentally retarded OSs'.