Does QNX 6.3.0 SP2 support any dual-core or 64-bit processors? If yes, what models does it support?
Dual Core yes, 64 bit only in 32 bit mode. There is a boot image for multi core machines that needs to be used to replace the .boot file, it is in /boot/build. But this is only for testing, if you want it for real you need the Multi Core TDK.
While were on it, a few questions. Is there anything different (other than physically) between two SMP processors and a Dual Core? Also, what does 64bit mean w/respect to these new processors? All registers are 64bit? A new running mode, like the 286->386 transition? Is there code compatibility, as in, can you run a 32 bit executable in 64 bit mode? Is there a mode bit, so that 32 bit executables can run under a 64bit OS? Just curious.
I don’t think it’s for testing only. If the smp .boot file fits your need there is no need to get the Multi-Core TDK which is very expensive.
As for as software is concern there is no difference, it’s totally transparent. As far as performance that gets complicated because it depends on processor brand and model, P4, Xeon, Conroe, AMD64, Opteron, then you can mix SMP and dual core (2 processors with 2 cores each). In a nutshell AMD has superior architecture and performance compare with P4 familly. But the Conroe familly is changing the tides in low and middle end (4 processors is still better run on AMD)
[/quote]
Yes but not only that but there are double the amount of registers and that is usually why 64 bit program runs faster (not because of increased memory address space) but then you need a good compiler for that.
Yes that is a nice way if seeing it, but one of the main difference between 286-386 is that int are still 32 bit they aren’t 64 bit. long long will use 64 bit registers natively
Yes but unless you want to switch back and forth, all the libraries (share object) must be of same time.
Under Windows XP 64 bits there is a layer that will transfer all 32 bit call to their 64 bit equivalent, thus Microsoft need only to maintain 1 version of everything. Apple on the other ends as a different philosophy where every DLL/shared object will contains both 64 and 32 bit flavor. So there is no need for an extra lawer. In fact under OSX you can have an executable/dll/shared object that contains native code for PowerPC x86/32 and x86/64.
[quote=“maschoen”]
Apparently support for x64/64 is somewhere on QSS’s roadmap, but don’t hold your breath.
If it fits your need for your development machine, yes you can use it. But as soon as you want to deploy Neutrino commercially, you need the license to do that. For SMP and Multicore systems, that means you need the MC TDK. In other words, commercially deploying Neutrino systems with that SMP image without having bought the MC TDK would be illegal.
AFAIK the price of the MC TDK depends on the amount of systems you want to deploy.
Given that soon all x86 processors will be multi-core. The fact that you have to pay LOTS of money for it is rather strange. To me that’s like paying extra for being able to use floating point.
The list price ofr TDK isn’t public, but I can tell you that for 200 runtime licenses the multi core TDK actually double the price of the runtime…
I disgress (told myself a while ago I would stick to technical issue), enough said.
Tell this to your QNX rep, Mario. I’m sure many people will tell similar things to their QNX reps, too. And then, QSS will need to react…
Not to defend or argue against any particular pricing scheme, this does show you some of the difficulties in trying to figure out pricing for a product like QNX. Imagine that someone comes to you with an embedded system that consists of a double motherboard with a single hard drive. Two complete systems on one board, but only one installation. Do you charge for one license or two? Now what happens if you have a dual core system, and someone runs a VM on top, so that they are now running to OS’s? As you can see this is a gray area. Double the cost for an SMP license (which probably covers any number of processors, 2, 4, 8, etc.) sounds like a reasonable place to start pricing. As Dual cores become more common, this will probably be adjusted downward.
Already done 
QSSL’s pricing and slowly but surely moving functinality from the core OS to the “TDKs” (e.g. the 3d tdk, the smp tdk, etc.) makes it so that is no longer the “no brainer” of real time operating systems.
The pricing is now similar to VxWorks, while VxWorks has a superior real time debugger and development environment. As my experiments with Qnet have shown, the real-time Qnet support isn’t quite what we all thought. I remember using Fleet with a 2 node real-time image processing/control system there were NO such jitter issues even with 1KHz control frequency.
The loss of the Proc32 option that let you set the “highest pri interrupt in the system” was another step away from that hard real-time system. I used to tie that IRQ to a timer board and come hell or high water my ISR would run.
Not sure where QSSL is heading but constantly unbundling features while raising the price makes it harder to convince your boss that it’s the way to go.
I tell you when it was $4K for a development seat that came w/everything including PhAB/Photon (qnx 4.25) it was just a no-brainer.
Not sure if that is good or bad 
That is subjective, of course.
What experiments? I’d like to hear about them.
This has not been lost, but since the startup is now coded by the customer, it is a simple matter to set up the hardware priorities any way you like (i.e. instead of being x86 specific it is now as configurable as whetever the PIC supports).
What experiments? I’d like to hear about them.
There’s a whole thread on this issue. Mario claims he duplicated the results. The amount of jitter was shockingly large. I haven’t tried to duplicate it yet. I would not say that the evidence so far points absolutely at QNET, but it is worrysome.
CAUTION GIANT WALL OF TEXT FOLLOWS
Being a “no brainer” is a good thing - means that when I presented $4k for the development system for an OS that had so many featured bundled, versus other RTOSs that required you to buy a gazillion different pieces to have the same functinality, the easy answer was “heck yeah get QNX why wouldn’t we”.
I’m a fan. Always have been. Converted the Clemson University Control/Robotics dept to QNX based software. Started a small company and sold QNX based software for control (Quality Real-Time Solutions) that evolved from my PhD work. I even still have my commercial QNX 4.25 license somewhere 
Now I work for Rockwell Collins doing flight sims and I’m trying to help them address some of their real-time needs.
I’m by no means a nay-sayer or critic of QNX. I’m just stating my findings and opinions. But you have to consider that I’m a “pro-qnx” guy trying to sell my bosses on the OS and what I’m saying is it’s a lot harder to do that with QNX in its current state than it was when QNX 4.25 was $4K for a full dev system
The Rockwell “approved” real-time OS is VxWorks, and I’ve had the opportunity to use it for a while, not nearly as much as I’ve used QNX 4.25. While in my opinion the OS is in many ways inferior, the dev tools are not, and the live and post-mortum debugging with windview is awesome. Of course nothing touches self-hosted debugging which was a real + for qnx 4.25 with the watcom tools but the eclipse toolset is so unstable (see my thread about it just locking up and forcing a system reboot to clear the JVM) that I can’t even demo that to my bosses because it is so “amateur night” compared to the windows version of the eclipse toolset.
Price is almost doubled from the QNX 4.25 days, functionality is removed from the OS to TDKs (OpenGL used to be bundled, not sure about SMP support), reliance on non-QSSL “community” software has increased (some see this as a plus, I don’t - if I want community I use Linux, for the applications where I see QNX as the right tool, I want absolute high quality and tight control and someone to hold responsible for that - I don’t want to be told to submit a patch as I’ve done w/the Linux kernel before - I lived through the 2.4.0-2.4.10 OOM killer issue with live servers I put in the field having kernel panics - 8 more minor releases after that we finally had a stable kernel).
The “deterministic” behavior of Qnet for use in distributed IO was like the one last advantage I could use, but that doesn’t seem to be there either. So why not just use RT-Linux - same price, the community support is much better for linux software, yeah you don’t have any sort of real-time distributed anything - but we don’t seem to here either. The self hosted tools are up-to-date and work right.
/rant off
My point is if, as a fan and user of QNX for at least 10+ years, I am having trouble justifying QNX 6 over VxWorks or RT-Linux or LynxOS, imagine what it must be like for an impartial person evaluating these OSs.
I remember the SMP TDK was around $30K? I may be wrong check with your QNX rep - but I did price it and the 3d toolkit last time around when I first got to rockwell.
About the Proc32 -i option - well maybe you can “write it yourself now” but the bottom line for users such as myself - before it worked by using an option, now - I am not sure how to implement it since I have to do it myself so it is effectively a feature that was lost to me
There are more issues around interrupts, priority of hardware interrupt is somewhat irrelevant as most QNX drivers use InterruptEventAttach, so processing of interrupt is done at a thread level . This issue has been discussed on this forum as well so I won’t go into the details, again.
I don’t understand. AFAIR, yes the dev seat for QNX 4.25 was much cheaper than Momentics PE is today. But it had much less to offer, too. But QNX 4.25 had more expensive runtime licenses. If I remember correctly actually there was nothing called ‘runtime licenses’, you had to buy almost a full dev seat for your target! That was, because there was no real difference between dev seat and target. But maybe I don’t remember right. Bottom line is though, that QNX Neutrino is much cheaper than QNX 4!
As for the TDK’s, there are a lot of them, but (still) most TDK’s actually represent features not everyone really needs. If this changes in the future, it would be kinda ridiculous, because it would be like buying a car, and if you want to drive it, you need a “Tire TDK” and a “Steering Wheel TDK”. 
Really? Please expand on that?
In low volume maybe but with higher volume you could buy run time license for as cheap as QNX6.
I know people that have commited to QNX6 but still use QNX4 that have the same price for both OS (runtime)
Momentics offers cross-development, for example. And not only for Windows, but also for Linux and Solaris… and despite all this, it also runs on QNX Neutrino itself. Much more CPU’s are now supported. Photon is much more powerful. The tools have the very valueable System Profler, the maybe less valueable System Builder, the Code Coverage, the Memory Analysis. And hey, Neutrino has threads! 
The same price like… 10 years ago? And that despite an inflation rate of about 2% per year? That isn’t bad.
So what, if I’m coming from QNX4 and simply migrating to QNX6. These issue are irrelavant. That has value to QSS not to me.
How much more is debatable
Not sure I understand. But I’m taking about today, for run time
I’m not complaining about pricing, I just think that some type of customers are ready to pay big dollars for some features, (SMP on PowerPC for example) but for typical ex QNX4/x86 user, the pricing doesn’t compare very well. And for the price I find the product (IDE) is definitely lacking in robustness, flexibility, performance and usability. Maybe in the next version or two.
Being a QNX parter, I have access to the software for free. If I would have had to pay for the IDE you could be sure I’d be asking for a refund…
While I disagree with you regarding the cross-development aspect being not relevant - given the fact that (unfortunately) most of us have to use Windows in every day live, for business, and privately, I do agree with you regarding QNX 4.25 OS features vs. QNX Neutrino - for long-time QNX 4 users, QNX Neutrino does not offer enough advantages vs. QNX 4 to be extremely attractive. That is, because QNX 4 is such a great OS already.