|
|
|
|
|
|
| Author |
Message |
Tore Skogly
*nix forums beginner
Joined: 17 Oct 2005
Posts: 12
|
 Posted: Sat Jun 10, 2006 11:50 am Post subject:
Re: Three monitors on FC5
|
|
|
Steve Martin wrote:
| Quote: |
That's gonna kinda make it hard to tell you what you're doing wrong...
|
Here is a more updated posting about this problem.
I just noticed that I forgot to post it on comp.os.linux.hardware.
====================================
I am struggling with a three monitor setup on a workstation running FC5.
The workstation should have three separate desktop (i.e the cursor should be
moving between all the monitors, but when an application is maximized it is
supposed to fill one screen - not all three).
I found a template xorg.conf file and by modifying it i managed to get a
signal to all monitors, but only flickering and no usable desktop.
I guess something is wrong in my /etc/X11/xorg.conf file, but I cannot see
what. I hope someone can identify the errors.
my xorg.conf file looks like this:
# Xorg configuration created by system-config-display
Section "ServerLayout"
Identifier "Multihead layout"
Screen "Left" LeftOf "Center"
Screen "Center" RightOf "Left"
Screen "Right" RightOf "Center"
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "Files"
# Multiple FontPath entries are allowed (they are concatenated together)
# By default, a font server independent of the X server is
# used to render fonts.
FontPath "unix/:7100"
EndSection
Section "Module"
Load "dbe"
Load "extmod"
Load "fbdevhw"
Load "glx"
Load "record"
Load "freetype"
Load "type1"
Load "dri"
EndSection
#########################################
# Force Xinerama or Clone mode #
#########################################
Section "ServerFlags"
Option "Xinerama" "on"
# Option "Clone" "on"
EndSection
Section "InputDevice"
# Specify which keyboard LEDs can be user-controlled (eg, with xset(1))
# Option "Xleds" "1 2 3"
# To disable the XKEYBOARD extension, uncomment XkbDisable.
# Option "XkbDisable"
# To customise the XKB settings to suit your keyboard, modify the
# lines below (which are the defaults). For example, for a non-U.S.
# keyboard, you will probably want to use:
# Option "XkbModel" "pc102"
# If you have a US Microsoft Natural keyboard, you can use:
# Option "XkbModel" "microsoft"
#
# Then to change the language, change the Layout setting.
# For example, a german layout can be obtained with:
# Option "XkbLayout" "de"
# or:
# Option "XkbLayout" "de"
# Option "XkbVariant" "nodeadkeys"
#
# If you'd like to switch the positions of your capslock and
# control keys, use:
# Option "XkbOptions" "ctrl:swapcaps"
# Or if you just want both to be control, use:
# Option "XkbOptions" "ctrl:nocaps"
#
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "no"
EndSection
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5"
Option "Emulate3Buttons" "yes"
EndSection
##############################################
# Monitors for first video card #
##############################################
#Section "Monitor"
# Identifier "ATIMonitor0"
# ModelName "Samsung SyncMaster 930B"
# HorizSync 30.0 - 81.0
# VertRefresh 56.0 - 75.0
# Option "dpms"
#EndSection
Section "Monitor"
Identifier "ATIMonitor0"
VendorName "Monitor Vendor"
ModelName "LCD Panel 1280x1024"
HorizSync 31.5 - 67.0
VertRefresh 50.0 - 75.0
Option "dpms"
EndSection
Section "Monitor"
Identifier "ATIMonitor1"
VendorName "Monitor Vendor"
ModelName "LCD Panel 1280x1024"
HorizSync 31.5 - 67.0
VertRefresh 50.0 - 75.0
Option "dpms"
EndSection
#Section "Monitor"
# Identifier "ATIMonitor1"
# ModelName "Samsung SyncMaster 930B"
# HorizSync 30.0 - 81.0
# VertRefresh 56.0 - 75.0
# Option "dpms"
#EndSection
#############################################
# Monitors for second video card #
#############################################
#Section "Monitor"
# Identifier "MatroxMonitor0"
# ModelName "Samsung SyncMaster 930B"
# HorizSync 30.0 - 81.0
# VertRefresh 56.0 - 75.0
# Option "dpms"
#EndSection
Section "Monitor"
Identifier "MatroxMonitor0"
VendorName "Monitor Vendor"
ModelName "LCD Panel 1280x1024"
HorizSync 31.5 - 67.0
VertRefresh 50.0 - 75.0
Option "dpms"
EndSection
#############################################
# First dual head ATI video card #
#############################################
Section "Device"
Identifier "Videocard0"
Driver "radeon"
VendorName "Videocard vendor"
BoardName "ATI Technologies Inc RV370 5B64 [FireGL V3100 (PCIE)]"
BusID "PCI:1:0:0"
Option "CRT2HSync" "31.0 - 81.0"
Option "CRT2VRefresh" "56 - 75"
Option "MonitorLayout" "LVDS, CRT"
Option "MetaModes" "1280x1024-1280x1024"
Option "CRT2Position" "RightOf"
Screen 0
EndSection
Section "Device"
Identifier "Videocard1"
Driver "radeon"
VendorName "Videocard Vendor"
BoardName "ATI Technologies Inc RV370 5B64 [FireGL V3100 (PCIE)]"
BusID "PCI:1:0:0"
Screen 1
EndSection
#############################################
# Second video card - Matrox G450 #
#############################################
Section "Device"
Identifier "MatroxG450"
Driver "mga"
VendorName "Videocard vendor"
BoardName "Matrox Graphics, Inc. G400/G450"
BusID "PCI:6:0:0"
Option "MonitorLayout" "LVDS"
EndSection
###########################################
# Screens for First Video Card #
###########################################
Section "Screen"
Identifier "Left"
Device "Videocard0"
Monitor "ATIMonitor0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1280x1024"
EndSubSection
EndSection
Section "Screen"
Identifier "Center"
Device "Videocard1"
Monitor "ATIMonitor1"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1280x1024"
EndSubSection
EndSection
###########################################
# Screens for First Video Card #
###########################################
Section "Screen"
Identifier "Right"
Device "MatroxG450"
Monitor "MatroxMonitor0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1280x1024"
EndSubSection
EndSection
Section "DRI"
Group 0
Mode 0666
EndSection
--
Regards,
ToreS |
|
| Back to top |
|
 |
Lasse Jensen
*nix forums beginner
Joined: 06 Mar 2005
Posts: 15
|
| Posted: Mon Jun 12, 2006 7:33 pm Post subject:
Re: system resolution
|
|
|
darklight wrote:
| Quote: | I need a system resolution of 400MHZ my system runs at 250MHZ
i need 400MHZ so i can use rosegarden. does any one know how to
raise the system frequency
IE
The kernel timer resolution is to low how do i increase it.
|
First, if were talking about the same thing, its hertz, not megahertz.
Anyway edit your .config and set CONFIG_HZ_1000 instead of CONFIG_HZ_250
and recompile.
--
Lasse Jensen [fafler at g mail dot com]
Linux, the choice of a GNU generation. |
|
| Back to top |
|
|
news@absamail.co.za
*nix forums addict
Joined: 19 Jul 2005
Posts: 52
|
| Posted: Sat Jul 01, 2006 4:22 pm Post subject:
Re: ARM 'pc' would have a market now ?
|
|
|
On Mon, 16 Jan 2006 20:02:48 +0000, Ste (news) wrote:
| Quote: | In article <Ar-dnZwOyKa5tVbeRVn-jQ@is.co.za>,
news@absamail.co.za> wrote:
But I still need eg. linux to eg. view *.ps or *.pdf or *.doc files etc.
You can do all that on RISC OS.  But I see what you mean.
Steve
|
Why would you want to pay more for an ARM except for the low power ?
So they must rely on better portable preformance.
And of course since linux is available for ARM, that's a strong point;
and as I said apparently 'my OS' [Oberon S3] is also ported.
It works like a forest fire: you've got to get the critical mass, of
users & contributors. That's why the simputer failed.
Even if RISC OS is the 'best', before you pay you want to be sure that
you can use what you know/trust. That's how M$loth rode on DOS to
success.
== Chris Glur. |
|
| Back to top |
|
|
news@absamail.co.za
*nix forums addict
Joined: 19 Jul 2005
Posts: 52
|
| Posted: Tue Jul 04, 2006 4:18 am Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
On Fri, 23 Jun 2006 10:49:02 +0100, John Cartmell wrote:
| Quote: | In article <pan.2006.06.22.04.43.56.101927@absamail.co.za>,
news <news@absamail.co.za> wrote:
I understand that ARM hardware was previously sold by Acorn ?
The ARM processors and computers using them were designed by Acorn.
That's before it was realised how superior ARM was, especially
for low current.
Acorn knew precisely what they had designed and made. The rest of the world
may have been a touch slower and mostly still haven't properly appreciated how
best it can work - being too inclined to tinker. ;-(
Of course ARM is now common in the more expensive super-portable.
But is it available as a commodity price box ?
There are many ways of obtaining ARM processors and machines using ARM
processors. This ng is mainly concerned with general purpose (home) computers
using ARM processors and developments of the RISC Operating System that Acorn
originally designed alongside their ARM processors. There is a range of such
machines available second hand (Acorn machines have generally had extremely
long useful lives) and two current computers - the A9home from Advantage 6 and
Iyonix pc from Castle. Both companies also produce solutions for industrial
applications and, as you know, ARM processors are available embedded in many
products.
Say what your specific interest is and I'm sure someone can guide you further.
|
I'm reluctant to open another can-of-worms.
I've wasted plenty time analysing various CPU architectures.
I would want them to run linux, or at least my preferred OS
[Oberon S3] which "has an ARM port". But I'm not sure that all
models are compatible. I'm confused at reading "26 bit emulator" ?
It's a bit like being called a "Ford motor vehicle" ?
Model A9: < 3 Watt , 600 gram; sounds good !
Several secondhand A7000 for a 'school' which lacks mains-electricity
could be of interest - shipped to S.Africa.
As a bonus I'd like to be able to do some hardware-hacking.
Access to a universal-bus, the way that PCs allowed easy
hardware customised extensions is probably not possible ?
Thanks for info.
== Chris Glur. |
|
| Back to top |
|
|
John Cartmell
*nix forums beginner
Joined: 04 Jul 2006
Posts: 1
|
| Posted: Tue Jul 04, 2006 4:13 pm Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
In article <pan.2006.07.03.01.28.59.846775@absamail.co.za>,
news <news@absamail.co.za> wrote:
| Quote: | Several secondhand A7000 for a 'school' which lacks mains-electricity
could be of interest - shipped to S.Africa.
|
Google for 'Solo Project'.
ExpLAN have been working for a long time on development of hardware that can
be used where there is no mains. They have worked for a complete solution and
with local partners. Don't expect details from them until such time as their
local partner has a specific solution ready in your area - but yes they had
the same hardware (ARM) starting point as the A9 developers, though the latter
is specifically designed for industry in the UK (and similar).
As I said before you need to say what your interests are before we can advise
in detail. The possibilities of ARM are wide and far-reaching.
BTW The discussions about 26 bit and 32 bit architecture won't make sense from
outside. Both architectures are 32 bit but the older one uses 6 of those bits
in a particular way. The latest chips won't allow that (even though the old
form was better) so there is need to update older software or apply a form of
emulation. Properly updated/new software will run on new and older hardware.
--
John Cartmell john@ followed by finnybank.com 0845 006 8822
Qercus magazine FAX +44 (0)8700-519-527 www.finnybank.com
Qercus - the best guide to RISC OS computing |
|
| Back to top |
|
|
Paul Gotch
*nix forums beginner
Joined: 10 Jan 2006
Posts: 3
|
| Posted: Wed Jul 05, 2006 8:31 am Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
In comp.sys.arm news <news@absamail.co.za> wrote:
| Quote: | [Oberon S3] which "has an ARM port". But I'm not sure that all
models are compatible. I'm confused at reading "26 bit emulator" ?
|
The 26 bit architecture was deprecated years ago and was completely removed
in ARMv6. You therefore need a software emulator to execute 26 bit code on a
modern ARM.
-p
--
Gotch, n. A corpulent beer-jug of some strong ware.
Gotch, v. To surprise with a remark that negates or usurps a remark
that has just been made.
-------------------------------------------------------------------- |
|
| Back to top |
|
|
Torben Ęgidius Mogensen
*nix forums beginner
Joined: 15 Apr 2005
Posts: 20
|
| Posted: Wed Jul 05, 2006 10:09 am Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
John Cartmell <john@cartmell.demon.co.uk> writes:
| Quote: | BTW The discussions about 26 bit and 32 bit architecture won't make sense from
outside. Both architectures are 32 bit but the older one uses 6 of those bits
in a particular way. The latest chips won't allow that (even though the old
form was better) so there is need to update older software or apply a form of
emulation. Properly updated/new software will run on new and older hardware.
|
I don't agree that the "old" way was better. While having the PSW use
the four upper bits of the PC and using the two low bits for processor
mode meant you could need only one save to save both PC and status
word, it did limit the number of modes to 4 and limited the PC range
to 256MB. While 256MB was enough in the 90s, it is a limitation today
(though you can argue that most of the RAM used on modern machines is
for data, not programs).
What I regret is that ARM didn't also move the PC to an unnumbered
register at the same time they moved the PSW out of the PC. It would
require a few extra instructions for saving and restoring the PC as
well as indirect jumps (such as function call returns) and
position-relative loads, but it would remove a number of special cases
in instructions for the case where one of the registers is the PC, and
it would leave one more register available for general use. It would
probably also simplify the pipeline.
Torben |
|
| Back to top |
|
|
Mikael Pettersson
*nix forums beginner
Joined: 29 Aug 2005
Posts: 16
|
| Posted: Wed Jul 05, 2006 11:33 am Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
In article <7zd5ck4b3p.fsf@app-4.diku.dk>,
Torben Ęgidius Mogensen <torbenm@app-4.diku.dk> wrote:
| Quote: | What I regret is that ARM didn't also move the PC to an unnumbered
register at the same time they moved the PSW out of the PC. It would
require a few extra instructions for saving and restoring the PC as
well as indirect jumps (such as function call returns) and
position-relative loads, but it would remove a number of special cases
in instructions for the case where one of the registers is the PC, and
it would leave one more register available for general use. It would
probably also simplify the pipeline.
|
Speaking in my role as a compiler & runtime system hacker, I think
that having the PC as a GPR is one of the nicest features of ARM!
Admittedly, the most important use of it is for PC-relative addressing,
so if Yet Another Silly Addressing Mode was invented for that
(ARM has way too many addressing modes, but it's instruction encoding
is crap so it needs them) plus new instructions for returns and
indirect calls, then having PC as a hidden register would be OK.
The incremental gain of going from 15 to 16 GPRs is rather small,
so I don't buy that argument. Improved pipeline, maybe, but I'm
no chip designer.
Straight-line code performance isn't everything. Constructing immediates,
function call/ret sequences, and linkage between separately compiled and/or
loaded modules are also very important, and PC-as-GPR does help those cases.
--
Mikael Pettersson (mikpe@csd.uu.se)
Computing Science Department, Uppsala University |
|
| Back to top |
|
|
druck
*nix forums beginner
Joined: 19 May 2005
Posts: 5
|
| Posted: Wed Jul 05, 2006 10:28 pm Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
On 5 Jul 2006 torbenm@app-4.diku.dk (Torben Ęgidius Mogensen) wrote:
| Quote: | John Cartmell <john@cartmell.demon.co.uk> writes:
BTW The discussions about 26 bit and 32 bit architecture won't make sense
from outside. Both architectures are 32 bit but the older one uses 6 of
those bits in a particular way. The latest chips won't allow that (even
though the old form was better) so there is need to update older software
or apply a form of emulation. Properly updated/new software will run on
new and older hardware.
I don't agree that the "old" way was better. While having the PSW use the
four upper bits of the PC and using the two low bits for processor mode
meant you could need only one save to save both PC and status word,
|
It was very clean, but because of this flag preserving became the defaco
standard for all procedure calls, and as we now know from performing 32bit
ports, its unnecessary in the vast majority of cases. In the few cases where
it is required, there is very little penalty from introducing callee branch
overs.
| Quote: | it did limit the number of modes to 4 and limited the PC range to 256MB.
While 256MB was enough in the 90s, it is a limitation today (though you can
argue that most of the RAM used on modern machines is for data, not
programs).
|
Its actually only 64MB of code space (2^26).
| Quote: | What I regret is that ARM didn't also move the PC to an unnumbered register
at the same time they moved the PSW out of the PC. It would require a few
extra instructions for saving and restoring the PC as well as indirect
jumps (such as function call returns) and position-relative loads,
|
Madness! For one you lose all PC relative memory accesses, and have to
introduce a whole new set of instructions. The same for calculated branches.
| Quote: | but it would remove a number of special cases in instructions for the case
where one of the registers is the PC, and it would leave one more register
available for general use. It would probably also simplify the pipeline.
|
But the entire point of using a GP register for the PC is it not then a
special case but handled in exactly the same way by the processor as any
other register, reducing complxity and power consumption. Its only a 'special
case' in the mind of the programmer, and I suggest an immediate upgrade.
---druck
--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/ |
|
| Back to top |
|
|
Torben Ęgidius Mogensen
*nix forums beginner
Joined: 15 Apr 2005
Posts: 20
|
| Posted: Thu Jul 06, 2006 8:57 am Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
druck <news@druck.freeuk.com> writes:
| Quote: | On 5 Jul 2006 torbenm@app-4.diku.dk (Torben Ęgidius Mogensen) wrote:
John Cartmell <john@cartmell.demon.co.uk> writes:
BTW The discussions about 26 bit and 32 bit architecture won't make sense
from outside. Both architectures are 32 bit but the older one uses 6 of
those bits in a particular way. The latest chips won't allow that (even
though the old form was better) so there is need to update older software
or apply a form of emulation. Properly updated/new software will run on
new and older hardware.
I don't agree that the "old" way was better. While having the PSW use the
four upper bits of the PC and using the two low bits for processor mode
meant you could need only one save to save both PC and status word,
It was very clean, but because of this flag preserving became the defaco
standard for all procedure calls, and as we now know from performing 32bit
ports, its unnecessary in the vast majority of cases. In the few cases where
it is required, there is very little penalty from introducing callee branch
overs.
it did limit the number of modes to 4 and limited the PC range to 256MB.
While 256MB was enough in the 90s, it is a limitation today (though you can
argue that most of the RAM used on modern machines is for data, not
programs).
Its actually only 64MB of code space (2^26).
|
These are 2^26 words of four bytes each, so 256MB.
| Quote: | What I regret is that ARM didn't also move the PC to an unnumbered register
at the same time they moved the PSW out of the PC. It would require a few
extra instructions for saving and restoring the PC as well as indirect
jumps (such as function call returns) and position-relative loads,
Madness! For one you lose all PC relative memory accesses, and have to
introduce a whole new set of instructions. The same for calculated branches.
|
The minimal requirement would be instructions for transferring the PC
to a normal register and vice versa (like was added for transferring
PSW). This would at most add one extra instruction to the cases where
the current ISA uses the PC in instructions, but often this is not
required (MOV PC, r14 comes to mind as a case that would be translated
into only one instruction). The main cases where translation isn't
1:1 are loading the PC from memory (for example, an LDM that restores
callee-saves registers and the returns from the call) and for
constant-pools in the code. For the LDM, you can use the "^" bit to
indicate that a load to the link register should be to the PC instead.
For position-relative loads, the best is probably to add a new
instruction. Position-relative stores are not very common, so only
loading would deserve a new instruction.
| Quote: | but it would remove a number of special cases in instructions for
the case where one of the registers is the PC, and it would leave
one more register available for general use. It would probably
also simplify the pipeline.
But the entire point of using a GP register for the PC is it not then a
special case but handled in exactly the same way by the processor as any
other register, reducing complxity and power consumption. Its only a 'special
case' in the mind of the programmer, and I suggest an immediate upgrade.
|
On the contrary, most programmers regard R15 as being "just another
register that just happens to hold the address of the next
instruction", but the hardware nearly always special-cases
instructions that use the PC. In the original ARM, the PC could be 8
or 12 bytes ahead of the current instruction depending on whether the
instruction is single-cycle or multiple-cycle. This was changed (I
don't recall exactly when, it may have been ARM 7 or ARM  so the PC
would always (when read as R15) be 8 bytes ahead, no matter how long
the pipeline is. But this has required two out-of-sync copies of the
PC: one for use as R15 and another for fetching instructions.
Additionally, several instructions modify their semantics when R15 is
used as source or destination. So allowing the PC to be used in all
instructions becomes a burden for the implementation.
Torben |
|
| Back to top |
|
|
Peter Naulls
*nix forums beginner
Joined: 06 Jul 2006
Posts: 1
|
| Posted: Thu Jul 06, 2006 3:01 pm Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
In message <7zac7n9kl7.fsf@app-4.diku.dk>
torbenm@app-4.diku.dk (Torben Ęgidius Mogensen) wrote:
| Quote: | druck <news@druck.freeuk.com> writes:
On 5 Jul 2006 torbenm@app-4.diku.dk (Torben Ęgidius Mogensen) wrote:
Its actually only 64MB of code space (2^26).
These are 2^26 words of four bytes each, so 256MB.
|
Not quite. Bits 0-1 = processor mode, Bits 2-25 = PC, Bits 26-32 =
flags. There are 24 bits of four byte words, or 26-bit addresseable.
--
Peter Naulls - peter@chocky.org | http://www.chocky.org/
----------------------------------------------------------------------------
RISC OS Community Wiki - add your own content | http://www.riscos.info/ |
|
| Back to top |
|
|
druck
*nix forums beginner
Joined: 19 May 2005
Posts: 5
|
| Posted: Thu Jul 06, 2006 5:00 pm Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
On 6 Jul 2006 torbenm@app-4.diku.dk (Torben Ęgidius Mogensen) wrote:
| Quote: | druck <news@druck.freeuk.com> writes:
On 5 Jul 2006 torbenm@app-4.diku.dk (Torben Ęgidius Mogensen) wrote:
it did limit the number of modes to 4 and limited the PC range to 256MB.
Its actually only 64MB of code space (2^26).
These are 2^26 words of four bytes each, so 256MB.
|
No, its 2^26 bytes as the bottom two bits are the mode flags, and the top 6
bits are the PSR flags, hence actually only 2^24 WORDs of PC range.
| Quote: | What I regret is that ARM didn't also move the PC to an unnumbered
register at the same time they moved the PSW out of the PC.
Madness! For one you lose all PC relative memory accesses, and have to
introduce a whole new set of instructions. The same for calculated
branches.
The minimal requirement would be instructions for transferring the PC
to a normal register and vice versa (like was added for transferring
PSW). This would at most add one extra instruction to the cases where
the current ISA uses the PC in instructions,
|
In otherwords a huge penalty on the most common data addressing mode, severly
impacting ipc.
| Quote: | but often this is not required (MOV PC, r14 comes to mind as a case that
would be translated into only one instruction).
|
It is only one instruction?
| Quote: | The main cases where translation isn't 1:1 are loading the PC from memory
(for example, an LDM that restores callee-saves registers and the returns
from the call) and for constant-pools in the code. For the LDM, you can
use the "^" bit to indicate that a load to the link register should be to
the PC instead. For position-relative loads, the best is probably to add a
new instruction. Position-relative stores are not very common, so only
loading would deserve a new instruction.
|
As I said; madness.
| Quote: | But the entire point of using a GP register for the PC is it not then a
special case but handled in exactly the same way by the processor as any
other register, reducing complxity and power consumption. Its only a
'special case' in the mind of the programmer, and I suggest an immediate
upgrade.
On the contrary, most programmers regard R15 as being "just another
register that just happens to hold the address of the next instruction",
but the hardware nearly always special-cases instructions that use the PC.
In the original ARM, the PC could be 8 or 12 bytes ahead of the current
instruction depending on whether the instruction is single-cycle or
multiple-cycle. This was changed (I don't recall exactly when, it may have
been ARM 7 or ARM so the PC would always (when read as R15) be 8 bytes
ahead, no matter how long the pipeline is. But this has required two
out-of-sync copies of the PC: one for use as R15 and another for fetching
instructions.
|
They aren't out of sync, they maintain a precise relationship of 8 bytes
apart.
| Quote: | Additionally, several instructions modify their semantics when R15 is used
as source or destination. So allowing the PC to be used in all
instructions becomes a burden for the implementation.
|
Theres far less specical cases than you think, and the current system is far
simpiler and more othorganal than introducing the frankly horrible bodges
which you have proposed above.
---druck
--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/ |
|
| Back to top |
|
|
Torben Ęgidius Mogensen
*nix forums beginner
Joined: 15 Apr 2005
Posts: 20
|
| Posted: Fri Jul 07, 2006 9:50 am Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
Peter Naulls <peter@chocky.org> writes:
| Quote: | In message <7zac7n9kl7.fsf@app-4.diku.dk
torbenm@app-4.diku.dk (Torben Ęgidius Mogensen) wrote:
druck <news@druck.freeuk.com> writes:
On 5 Jul 2006 torbenm@app-4.diku.dk (Torben Ęgidius Mogensen) wrote:
Its actually only 64MB of code space (2^26).
These are 2^26 words of four bytes each, so 256MB.
Not quite. Bits 0-1 = processor mode, Bits 2-25 = PC, Bits 26-32 =
flags. There are 24 bits of four byte words, or 26-bit addresseable.
|
Right. I forgot the interrupt flags, so I counted only the four
arithmetic flags.
Torben |
|
| Back to top |
|
|
Wilco Dijkstra
*nix forums beginner
Joined: 11 Jan 2006
Posts: 2
|
| Posted: Sun Jul 09, 2006 4:53 pm Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
""Torben Ęgidius Mogensen"" <torbenm@app-4.diku.dk> wrote in message
news:7zd5ck4b3p.fsf@app-4.diku.dk...
| Quote: | John Cartmell <john@cartmell.demon.co.uk> writes:
BTW The discussions about 26 bit and 32 bit architecture won't make sense
from
outside. Both architectures are 32 bit but the older one uses 6 of those
bits
in a particular way. The latest chips won't allow that (even though the
old
form was better) so there is need to update older software or apply a
form of
emulation. Properly updated/new software will run on new and older
hardware.
I don't agree that the "old" way was better.
|
Indeed. There is no benefit from having a BL preserve the flags. The only
feature I miss in assembly programming is the ability to write 4 random
bits in the NZCV flags in a single instruction and then conditionally
execute
instructions based on the flags. This is useful for fast bitblitting.
| Quote: | What I regret is that ARM didn't also move the PC to an unnumbered
register at the same time they moved the PSW out of the PC.
|
Thumb-2 has effectively done this. Most uses of the PC are forbidden,
and the encoding is used for other purposes. MUL is now an encoding
of MLA with R15 as the accumulator (which reads as zero) rather than
using another opcode. The MOV/MVN/CMP/CMN instructions are
special cases of 3-operand instructions using R15 as a register
containing all ones or zeroes. There is a new addressing mode for
PC-relative loads, and all effective addresses can now be generated
using a single add instruction.
| Quote: | It would
require a few extra instructions for saving and restoring the PC as
well as indirect jumps (such as function call returns) and
position-relative loads, but it would remove a number of special cases
in instructions for the case where one of the registers is the PC, and
it would leave one more register available for general use. It would
probably also simplify the pipeline.
|
LDR pc,[...] and POP {...,pc} were kept since these are very common
return instructions. However you're right in that the first can be replaced
by the latter in most cases and special instructions could be introduced
to handle the few cases where the PC is currently needed. Thumb-2
introduced TBB for switch statements so you don't need the odd
ADD pc,pc,rx,LSL #2 anymore. There are few uses of the PC in
compiled code nowadays and that is how it should be.
I agree that having the PC and SP as general purpose registers
was a really bad idea. They introduce too many special cases that
need checking in both hardware and software (compilers/assemblers),
and that while almost all of those instructions are totally useless...
I don't think the pipeline is affected much, it is mainly decode and
validation. One of the good things in Thumb-1 is that it added special
instructions to deal with PC or SP (PUSH/POP/ADR etc). Thumb-2
continues this and made just about all odd uses of PC/SP illegal.
Wilco |
|
| Back to top |
|
|
Torben Ęgidius Mogensen
*nix forums beginner
Joined: 15 Apr 2005
Posts: 20
|
| Posted: Mon Jul 10, 2006 8:11 am Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
"Wilco Dijkstra" <Wilco_dot_Dijkstra@ntlworld.com> writes:
| Quote: | ""Torben Ęgidius Mogensen"" <torbenm@app-4.diku.dk> wrote in message
news:7zd5ck4b3p.fsf@app-4.diku.dk...
What I regret is that ARM didn't also move the PC to an unnumbered
register at the same time they moved the PSW out of the PC.
Thumb-2 has effectively done this. Most uses of the PC are forbidden,
and the encoding is used for other purposes. MUL is now an encoding
of MLA with R15 as the accumulator (which reads as zero) rather than
using another opcode. The MOV/MVN/CMP/CMN instructions are
special cases of 3-operand instructions using R15 as a register
containing all ones or zeroes. There is a new addressing mode for
PC-relative loads, and all effective addresses can now be generated
using a single add instruction.
|
Interesting. Thanks for the info. I must admit that I haven't
studied Thumb2 in any detail yet, but I plan to do so soon.
Having a "register" that takes on special values (0, -1, PC, ...)
depending on the instruction seems more useful than the constant-zero
register you find on MIPS and others.
Torben |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Wed Dec 03, 2008 9:01 pm | All times are GMT
|
|
Bad Credit Mortgages | Credit Cards UK | Internet Advertising | Personal Loans | Mobile Phones
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
Linux
»
hardware
