About programing, a general question

[Jerry Feldman]

On 12/22/2010 05:31 AM, les wrote:
>
> But as I recall, the alpha had some vector extensions and bytecoding
> extensions that enabled faster indexing, which is why it ran faster with
> indexed arrays ;-)
>
> And as to representation, if you go to assembly language the choice of
> octal or hex is often based upon the instruction declination of the
> processor.  For example the 8080 was octal, because the first 2 bits had
> a specific segmentation of the instruction set, the next three could
> choose a register or memory and the final three would make a choice
> based upon the other two groups.
>
> In the 6800 and later motorola processors, the representation was hex,
> reflecting a broader register base and larger instruction flexibility.  
>
> Now that we have 64 bit processors, and multiple cores, the next step
> will be a supervisor for the cores and then a new partitioning of the
> instruction word, and I expect a new notation, probably 64 base of some
> kind, because it will reflect the new reality of the core processors and
> their inherent capabilities.
>
>
Since I cowrote the Alpha assembler for Windows NT and Tru64 Unix. Most
of the RISC chips had a large number of general purpose registers. The
trick is to use them effectively. You can easily use one as a base
register and one as an index register. Octal and Hex are just shorthand
notations for expressing binary. In the early days of computing things
were not standardized. For instance, the DEC PGP-8 was a 12-bit machine.
Octal was much more convenient for PDP-8s. Systems based on the byte
generally use hex. I would expect that some of the new processors have
some form of virtualization manager. Can you see Intel chips with a
VMWare supervisor and AMD chips with a Microsoft Hyper V.

I did spend a bit of time working on Intel's IA64 systems. But, try to
read the object code without having a nervous breakdown.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20101222/4dc0a6a9/attachment.bin