Possibly by having comments in the code;) Also, remember that 40G covers all kinds of applications that come with it. The equivalent would be to include the Linux kernel and every other application equivalent that is delivered with Windows 2000.
As others have said, the 68k has 8 data and 8 address registers. All commands that allow a data register as an opperand will allow *any* data register as a legal operand. The same is for the address registers (and in fact, for many operations you can use the address registers as general purpose). There simply *is no* with instruction XYZ I have to have my operand in registerA and my destination in registerB. This allows a lot more flexibility in where you can do your temporary calculations and such. For example, you need to add two values from memory to get an intermediate value in the middle of your main calculation loop? On the 68k and most load/store architectures, simply pick a data register not in use, use it to calculate the intermediate, then apply that result to your ongoing result. On the x86, depending on your calculation stream, you may have to save the contents of a particular register out to memory because the next instruction you want to use to calculate your intermediate must use a specific register for its operand(s) or result and you are already using that register because your outer calculation must also use that exact register. For some calculations, you effectively have only one register you can use and you have to shuffle intermediates to/from memory much more than if you had real general purpose registers
Also, the 68k has a flat memory model. You want to much around with 64K + 1 byte of data? there's no difference in addressing array[0] or array[65536]. You can even do them back to back with no other instructions in between. 2MBytes? same thing. In the x86 segmented memory model, either of these two scenarios become quite a bit more painful.
Basically it comes down to the orthogonality of the ISA between the two. The 68k family had a much higher degree of orthogonality than the x86 family.
Things are even better on most load/store processors where you typically have 31 (or more) registers that are completely general purpose and the ALU instructions are almost completely orthogonal and memory is flat.
I agree. It's rather unfortunate that one of the most ugly, ungainly, and hacked ISAs out there is also the dominant one. There are some assemblies that are a pleasure to use, though. The 68K line and almost all of the load/store ISAs are nice to use. Some of the older *really* CISC ones are OK too.
Ah... but there's the rub... Historically, people have wanted to use the same thing at home as they did at work. This actually benefits companies in that "training" is done at home because the user simply uses what they have at home. I guess you could argue that putting Linux in all the businesses will force people to write entertainment software on Linux because people who use Linux at work will install it at home, but I don't see this path happening because of the chicken/egg problem. Folks may use Linux at work, but since all they can do on it is work, they won't use it at home (no entertainment). Because no one is using it at home, no entertainment will be derived from it.
And in all this, there still lies the fact that it takes big $$$ to make a game... money that is frequently funded up front and attempted to be recovered on release of the game. It takes many 1000s (1,000,000s?) of person-hours of work to make a game. Those programmers typically work 80 hour weeks for a year or more. Who would be willing to do that for free? especially when the end result will probably have to be given away free because of GPL and such. It just doesn't add up.
Until Linux is a complete entertainment package as well as a utility package, Linux will be hard pressed to take over the desktop.
With the way games are written these days (requiring massive amounts of time and money), game development will have to undergo some pretty radical changes before it will fit successfully into the OSS model and we continue to have the quality of games we have today.
Of course, the other path is that the PC is removed from the entertainment picture and consoles take over that role completely (woe be that day).
You forget that the standards for these graphics cards are dictated by the HARDWARE designers, and area in which M$ expertise is measured in negative numbers.
I'm not sure as to which graphics cards your "these" refers. However, in the PC world, at least for the past few years, the DirectX API and standards were put forth before hardware was designed to support the API. Even back in the days of MSDOS, graphics cards APIs were completely non-standard. If you go back and actually look at games that were out then, you'd find that they supported generic VGA modes, then a number of specialized modes that corresponded to different manufacturers specialized extentions or APIs (Tandy, GLide, etc. for instance) Even GL cards were designed to support the SGI GL graphics API until GL was turned into OpenGL, at which time graphics cards were designed to support that API (and OpenGL2).
Unix V7 machines were not affordable to the general populace back then. The PC made machines cheap so that people could afford many of them in comparison to a single time-shared server running one of the various flavors of Un*x. You could buy one PC for a few thousand dollars or a Unix time-shared machine for many thousands of dollars. For small companies, this was an easy choice.
The fact is that the Microsoft/Intel alliance has made computing as easy and as prevalent as it is today, regardless. If we still lived in the world of the time-shared Unix servers, we'd still be using Curses as our UI and no one would have computers at home.
As far as who took over, it is as much a fault of the Unix elitists and their expensive hardware not making computing available to the general public and cheaply enough to win as it is the fault of some companies who saw the opportunity and capitalized on it.
MS and Gates has done far more damage than good to this industry
Very hard to measure. Because Windows was such a dominant part of the marketplace, the hardware platforms stabilized and became a "common" platform, something that Linux takes great advantage of in the x86 world, as much or more so than Windows itself (since Linux didn't have to pay at all to reap the benefits of an x86 common platform).
Because of platform standardization, we have graphics cards that are incredibly fast that do not cost a fortune, which they would have if there were no standard API (full OpenGL cards still cost a fortune - slimmed down OpenGL had to come about to compete with DirectX - at one time, most games were written in GLiDE or [Open]GL but have almost all switched).
Because of platform standardization, we have lots of hardware vendors make competing hardware instead of just a few companies making non-standard products (as it was back in the late 80s and early 90s). Again, something that Linux takes full advantage of with no/little cost. Because of platform standardization, it was easy to churn out commodity computers at low prices so that practically everyone in the USA and Europe now has an x86 PC in their home and they almost all use software that "talks" to everyone else's machine - again, very much unlike the computers up to the early 90s.
Maybe folks don't remember the 80s and early 90s. I remember them fondly as a computer geek. Computers were a wonder and there were as many platforms as there were leaves on a tree, each with its own special features and nuances that made each platform have a coolness factor and made you want to learn all the details.
However, software companies had to have large/huge investments in personnel and logistics to support the many platforms that were in existance and eventually, some of those less adopted platforms began to fall by the wayside because of the effort that it took to support it was not worth the amount of money that the company would make. There was little/no compatibility and every company that wanted to sell to a large market (and make some money in the process) was re-inventing the wheel in incompatible ways several times over to support all these platforms.
When IBM pushed their platform, companies enjoyed having to write and support only one product. Costs lowered, sales expanded as more people adopted that platform, and it was a self-feeding system. The more software you had, the more people adopted the platform, the more software could be written and distributed to a larger market. As Intel's mantra goes: hardware is nothing without software (ok, they kinda departed this on Itanium, but that's why the latest P4 can still run most, if not all, 8086/8088 code).
Because of the consolidation on basically a single commodity platform, even Linux (sure, Linux runs on a variety of platforms, but count the number of installations that are on x86 PCs as compared to any other non-embedded platform) has enjoyed the same benefit that all the other software companies have enjoyed - a very large number of common platforms on which to run.
Add this to the fact that some folks simply hate Microsoft and will run anything else other than Windows to do work or play and you have the fact that Linux exists and owes its popularity almost entirely to the Microsoft/Intel alliance.
Don't know how they could be exactly the same *except* for the word size. In order to process the two different word sizes, there will have to be differences in circuitry (ALU is wider, so are lots of things like the buffers between pipeline stages and such).
One of the issues that people forget is that a 64-bit processor may be able to retire a set number of 64-bit, say, integer additions per clock cycle (NOTE: retiring an operation per clock cycle does NOT mean that the operation takes one clock cycle to perform). Well, the odds are that it will also retire the same number of 32-bit integer additions per clock cycle. It may take 5 clock cycles to do either sized addition even. So, what do you have that is different? Well, on the SPARC, most simple operations are going to be similar in execution time. Regarless of the number of register windows that the particular architecture supports (which may come into play in some codes), you still basically have 32 registers for use in your computational kernel. The only real difference between many 32-bit and 64-bit versions of the code will be the amount of data that has to be moved around.
Where the 64-bit will help is when the 32-bit code has to synthesize 64-bit operations or has to do things like work on bit streams (not word/byte streams exactly) and can work on 64-bits at a time rather than doing really the same thing on 32-bits two times as much (128 bytes can be traversed in 32 32-bit operations or 16 64-bit operations - half the number of reads/operations).
All of this is pretty well understood by those who have dealt with these type systems before. However, the relative newcomer Opteron has an additional twist. In 64-bit mode, there are twice as many registers that can be used compared to 32-bit mode. This may (read: will) cause some codes to be done faster simply because more data can be stored in registers rather than memory, even L1 cache is a bit slower than a register.
Don't confuse a monopoly with being one product. For example, if Microsoft had both a Windows and a Linux distribution and the two OS's were 50/50 in sales, Microsoft could still engage in monopolistic practices (as per the court ruling) but (in the context of this article) a virus that would effect Microsoft Windows may have no impact on Microsoft Linux.
Fact 2: During medieval times, when development (sustainable and not so) came to a standstill to be replaced with petty wars, people were sicker and lived shorter life spans than ever before.
"Sicker" I dunno, but I imagine lots of folks being killed, not by old age, but by metal and wooden bits being rammed into them or driven through them, would tend to skew some numbers here... You have to be careful of which numbers you use...
Cross reference this with a lot of the discussion of nanotechnology recently... for instance the discussion of the two heads of different camps discussion recently on slashdot (not taking the time to find the link). Anyway, one of the leading guys says that nanotechnology will be built using organics, the other says by mechanics and each say the other is wrong. Anyway, understanding how and why "transition metals are essential to the formation of a non crystalline biological material" may help in the building of nanotechnology science.
In many places in the US, owning a car is not simply a luxury, it is required. Public mass transportation is not feasible in many places because population density is low which would equate to high costs of the public transportation system (fuel, maintenance, etc). However, it is always your choice as to what automobile you buy, the small affordable one or the big flashy car.
It's not like you can't have two CPUs and still have cache issues with shared data if you wrote your app poorly. A heavily accessed and modified datum by both threads running on two seperate processors would have a lot of snoop logic firing between the two CPUs which would slow things down dramatically.
unless you are only running apps that are heavily optimized and multithreaded....or running two apps at the same time that both like to hog the CPU. What matters is that you have two threads (and they don't have to necessarily in the same process) that need CPU resources. Even outside of this case, you always have the kernel that will need to run, various services/daemons that will need to wake up from time to time and look around for something to do, and interrupts to process so the machine should feel more responsive and perhaps you may see small (single digit % increases) in many things.
It is a business model... but some folks for some reason take it to be something of a physical constant or a physical law, like the speed of light or gravity.
Moore's Law is about the pace of advancement of transistor size with what the market will bear in buying upgrades/new machines. It has almost nothing to do with how rapidly photolithography size reductions can be developed or implemented.
I keep telling her that for the number of people and amount of effort involved, they could write their own FOSS application to do the same thing, and spend their time making improvements rather than restoring last year's hacks year after year.
This is assuming that their changes are accepted into the root source tree (which is a false assumption). If the changes/features are too specialized/customized (they apply to only that particular college) and if they interfere with other features, they most likely will not be accepted and they will be in exactly the same boat as they are in now.
Just because a particular software package is "OpenSource" does not imply that any and all features will be put into the root source tree.
It's much easier to do (not that it isn't as hard as hell - just a lot easier) when you control your hardware. Apple maintains control over its hardware which makes the OS easier to build and maintain as well. If Apple had 100s (if not 1000s) of companies that built hardware for the machine that were required to update all their drivers and such, they'd have had a much more difficult time at it.
And how much of this is because of 64-bit? The memory architecture of a dual Opteron is much better for high memory loads than a dual Xeon (independent memory bus for each processor, for starters), which Anand even attributes the performance increase (speaks of the on-cpu-die memory controller) in his Final Words
Some people really CAN drive while on a cell phone. If you can't, you should be responsible enough to refrain.
This is exactly the point. Very few people will honestly admit to themselves that they can't - especially when they see other people doing it. This would be an honest admission that they are somehow inferior to others, which is a difficult thing for many people to do. The vast majority of people think that they can, even despite evidence to the contrary. I know plenty of people who think they are the best drivers on the road even though many of their friends are nervous about riding in a vehicle they are driving.
In the end, what you have is almost everyone driving and doing these things and being a hazard on the road. The only fair way to do this, to many folks, is to universally ban it. If you start making tests to allow some and not others, you will get lawsuits of descrimination, racial profiling, and all of those similar garbage things.
Not only that, but how would you enforce the law? Stop everyone and see if they are allowed? or simply not stop anyone for it unless there is another reason (speeding/wreck/suspicion of chemical influence/etc).
Slashdot Mirror
Possibly by having comments in the code ;) Also, remember that 40G covers all kinds of applications that come with it. The equivalent would be to include the Linux kernel and every other application equivalent that is delivered with Windows 2000.
You say this as if you think that base-3 and base-10 logic (as well as just analog) had never been used before...
As others have said, the 68k has 8 data and 8 address registers. All commands that allow a data register as an opperand will allow *any* data register as a legal operand. The same is for the address registers (and in fact, for many operations you can use the address registers as general purpose). There simply *is no* with instruction XYZ I have to have my operand in registerA and my destination in registerB. This allows a lot more flexibility in where you can do your temporary calculations and such. For example, you need to add two values from memory to get an intermediate value in the middle of your main calculation loop? On the 68k and most load/store architectures, simply pick a data register not in use, use it to calculate the intermediate, then apply that result to your ongoing result. On the x86, depending on your calculation stream, you may have to save the contents of a particular register out to memory because the next instruction you want to use to calculate your intermediate must use a specific register for its operand(s) or result and you are already using that register because your outer calculation must also use that exact register. For some calculations, you effectively have only one register you can use and you have to shuffle intermediates to/from memory much more than if you had real general purpose registers
Also, the 68k has a flat memory model. You want to much around with 64K + 1 byte of data? there's no difference in addressing array[0] or array[65536]. You can even do them back to back with no other instructions in between. 2MBytes? same thing. In the x86 segmented memory model, either of these two scenarios become quite a bit more painful.
Basically it comes down to the orthogonality of the ISA between the two. The 68k family had a much higher degree of orthogonality than the x86 family.
Things are even better on most load/store processors where you typically have 31 (or more) registers that are completely general purpose and the ALU instructions are almost completely orthogonal and memory is flat.
I agree. It's rather unfortunate that one of the most ugly, ungainly, and hacked ISAs out there is also the dominant one. There are some assemblies that are a pleasure to use, though. The 68K line and almost all of the load/store ISAs are nice to use. Some of the older *really* CISC ones are OK too.
Ah... but there's the rub... Historically, people have wanted to use the same thing at home as they did at work. This actually benefits companies in that "training" is done at home because the user simply uses what they have at home. I guess you could argue that putting Linux in all the businesses will force people to write entertainment software on Linux because people who use Linux at work will install it at home, but I don't see this path happening because of the chicken/egg problem. Folks may use Linux at work, but since all they can do on it is work, they won't use it at home (no entertainment). Because no one is using it at home, no entertainment will be derived from it.
And in all this, there still lies the fact that it takes big $$$ to make a game... money that is frequently funded up front and attempted to be recovered on release of the game. It takes many 1000s (1,000,000s?) of person-hours of work to make a game. Those programmers typically work 80 hour weeks for a year or more. Who would be willing to do that for free? especially when the end result will probably have to be given away free because of GPL and such. It just doesn't add up.
...and they had CPUs that ran native LISP as well, while interesting, they weren't practical.
Until Linux is a complete entertainment package as well as a utility package, Linux will be hard pressed to take over the desktop.
With the way games are written these days (requiring massive amounts of time and money), game development will have to undergo some pretty radical changes before it will fit successfully into the OSS model and we continue to have the quality of games we have today.
Of course, the other path is that the PC is removed from the entertainment picture and consoles take over that role completely (woe be that day).
Your logic is completely flawed. According to you, Microsoft only cares about making money, yet they won't sell a product to make the money.
You forget that the standards for these graphics cards are dictated by the HARDWARE designers, and area in which M$ expertise is measured in negative numbers.
I'm not sure as to which graphics cards your "these" refers. However, in the PC world, at least for the past few years, the DirectX API and standards were put forth before hardware was designed to support the API. Even back in the days of MSDOS, graphics cards APIs were completely non-standard. If you go back and actually look at games that were out then, you'd find that they supported generic VGA modes, then a number of specialized modes that corresponded to different manufacturers specialized extentions or APIs (Tandy, GLide, etc. for instance) Even GL cards were designed to support the SGI GL graphics API until GL was turned into OpenGL, at which time graphics cards were designed to support that API (and OpenGL2).
Unix V7 machines were not affordable to the general populace back then. The PC made machines cheap so that people could afford many of them in comparison to a single time-shared server running one of the various flavors of Un*x. You could buy one PC for a few thousand dollars or a Unix time-shared machine for many thousands of dollars. For small companies, this was an easy choice.
The fact is that the Microsoft/Intel alliance has made computing as easy and as prevalent as it is today, regardless. If we still lived in the world of the time-shared Unix servers, we'd still be using Curses as our UI and no one would have computers at home.
As far as who took over, it is as much a fault of the Unix elitists and their expensive hardware not making computing available to the general public and cheaply enough to win as it is the fault of some companies who saw the opportunity and capitalized on it.
MS and Gates has done far more damage than good to this industry
Very hard to measure. Because Windows was such a dominant part of the marketplace, the hardware platforms stabilized and became a "common" platform, something that Linux takes great advantage of in the x86 world, as much or more so than Windows itself (since Linux didn't have to pay at all to reap the benefits of an x86 common platform).
Because of platform standardization, we have graphics cards that are incredibly fast that do not cost a fortune, which they would have if there were no standard API (full OpenGL cards still cost a fortune - slimmed down OpenGL had to come about to compete with DirectX - at one time, most games were written in GLiDE or [Open]GL but have almost all switched).
Because of platform standardization, we have lots of hardware vendors make competing hardware instead of just a few companies making non-standard products (as it was back in the late 80s and early 90s). Again, something that Linux takes full advantage of with no/little cost. Because of platform standardization, it was easy to churn out commodity computers at low prices so that practically everyone in the USA and Europe now has an x86 PC in their home and they almost all use software that "talks" to everyone else's machine - again, very much unlike the computers up to the early 90s.
Maybe folks don't remember the 80s and early 90s. I remember them fondly as a computer geek. Computers were a wonder and there were as many platforms as there were leaves on a tree, each with its own special features and nuances that made each platform have a coolness factor and made you want to learn all the details.
However, software companies had to have large/huge investments in personnel and logistics to support the many platforms that were in existance and eventually, some of those less adopted platforms began to fall by the wayside because of the effort that it took to support it was not worth the amount of money that the company would make. There was little/no compatibility and every company that wanted to sell to a large market (and make some money in the process) was re-inventing the wheel in incompatible ways several times over to support all these platforms.
When IBM pushed their platform, companies enjoyed having to write and support only one product. Costs lowered, sales expanded as more people adopted that platform, and it was a self-feeding system. The more software you had, the more people adopted the platform, the more software could be written and distributed to a larger market. As Intel's mantra goes: hardware is nothing without software (ok, they kinda departed this on Itanium, but that's why the latest P4 can still run most, if not all, 8086/8088 code).
Because of the consolidation on basically a single commodity platform, even Linux (sure, Linux runs on a variety of platforms, but count the number of installations that are on x86 PCs as compared to any other non-embedded platform) has enjoyed the same benefit that all the other software companies have enjoyed - a very large number of common platforms on which to run.
Add this to the fact that some folks simply hate Microsoft and will run anything else other than Windows to do work or play and you have the fact that Linux exists and owes its popularity almost entirely to the Microsoft/Intel alliance.
Don't know how they could be exactly the same *except* for the word size. In order to process the two different word sizes, there will have to be differences in circuitry (ALU is wider, so are lots of things like the buffers between pipeline stages and such).
One of the issues that people forget is that a 64-bit processor may be able to retire a set number of 64-bit, say, integer additions per clock cycle (NOTE: retiring an operation per clock cycle does NOT mean that the operation takes one clock cycle to perform). Well, the odds are that it will also retire the same number of 32-bit integer additions per clock cycle. It may take 5 clock cycles to do either sized addition even. So, what do you have that is different? Well, on the SPARC, most simple operations are going to be similar in execution time. Regarless of the number of register windows that the particular architecture supports (which may come into play in some codes), you still basically have 32 registers for use in your computational kernel. The only real difference between many 32-bit and 64-bit versions of the code will be the amount of data that has to be moved around.
Where the 64-bit will help is when the 32-bit code has to synthesize 64-bit operations or has to do things like work on bit streams (not word/byte streams exactly) and can work on 64-bits at a time rather than doing really the same thing on 32-bits two times as much (128 bytes can be traversed in 32 32-bit operations or 16 64-bit operations - half the number of reads/operations).
All of this is pretty well understood by those who have dealt with these type systems before. However, the relative newcomer Opteron has an additional twist. In 64-bit mode, there are twice as many registers that can be used compared to 32-bit mode. This may (read: will) cause some codes to be done faster simply because more data can be stored in registers rather than memory, even L1 cache is a bit slower than a register.
Don't confuse a monopoly with being one product. For example, if Microsoft had both a Windows and a Linux distribution and the two OS's were 50/50 in sales, Microsoft could still engage in monopolistic practices (as per the court ruling) but (in the context of this article) a virus that would effect Microsoft Windows may have no impact on Microsoft Linux.
Choose your own Adventure book?
Fact 2: During medieval times, when development (sustainable and not so) came to a standstill to be replaced with petty wars, people were sicker and lived shorter life spans than ever before.
"Sicker" I dunno, but I imagine lots of folks being killed, not by old age, but by metal and wooden bits being rammed into them or driven through them, would tend to skew some numbers here... You have to be careful of which numbers you use...
Cross reference this with a lot of the discussion of nanotechnology recently... for instance the discussion of the two heads of different camps discussion recently on slashdot (not taking the time to find the link). Anyway, one of the leading guys says that nanotechnology will be built using organics, the other says by mechanics and each say the other is wrong. Anyway, understanding how and why "transition metals are essential to the formation of a non crystalline biological material" may help in the building of nanotechnology science.
In many places in the US, owning a car is not simply a luxury, it is required. Public mass transportation is not feasible in many places because population density is low which would equate to high costs of the public transportation system (fuel, maintenance, etc). However, it is always your choice as to what automobile you buy, the small affordable one or the big flashy car.
It's not like you can't have two CPUs and still have cache issues with shared data if you wrote your app poorly. A heavily accessed and modified datum by both threads running on two seperate processors would have a lot of snoop logic firing between the two CPUs which would slow things down dramatically.
unless you are only running apps that are heavily optimized and multithreaded. ...or running two apps at the same time that both like to hog the CPU. What matters is that you have two threads (and they don't have to necessarily in the same process) that need CPU resources. Even outside of this case, you always have the kernel that will need to run, various services/daemons that will need to wake up from time to time and look around for something to do, and interrupts to process so the machine should feel more responsive and perhaps you may see small (single digit % increases) in many things.
It is a business model... but some folks for some reason take it to be something of a physical constant or a physical law, like the speed of light or gravity.
Moore's Law is about the pace of advancement of transistor size with what the market will bear in buying upgrades/new machines. It has almost nothing to do with how rapidly photolithography size reductions can be developed or implemented.
I keep telling her that for the number of people and amount of effort involved, they could write their own FOSS application to do the same thing, and spend their time making improvements rather than restoring last year's hacks year after year.
This is assuming that their changes are accepted into the root source tree (which is a false assumption). If the changes/features are too specialized/customized (they apply to only that particular college) and if they interfere with other features, they most likely will not be accepted and they will be in exactly the same boat as they are in now.
Just because a particular software package is "OpenSource" does not imply that any and all features will be put into the root source tree.
...and why there is .NET
On Windows, search for MemoryMappedFile. The equivalent to mmap.
It's much easier to do (not that it isn't as hard as hell - just a lot easier) when you control your hardware. Apple maintains control over its hardware which makes the OS easier to build and maintain as well. If Apple had 100s (if not 1000s) of companies that built hardware for the machine that were required to update all their drivers and such, they'd have had a much more difficult time at it.
And how much of this is because of 64-bit? The memory architecture of a dual Opteron is much better for high memory loads than a dual Xeon (independent memory bus for each processor, for starters), which Anand even attributes the performance increase (speaks of the on-cpu-die memory controller) in his Final Words
Some people really CAN drive while on a cell phone. If you can't, you should be responsible enough to refrain.
This is exactly the point. Very few people will honestly admit to themselves that they can't - especially when they see other people doing it. This would be an honest admission that they are somehow inferior to others, which is a difficult thing for many people to do. The vast majority of people think that they can, even despite evidence to the contrary. I know plenty of people who think they are the best drivers on the road even though many of their friends are nervous about riding in a vehicle they are driving.
In the end, what you have is almost everyone driving and doing these things and being a hazard on the road. The only fair way to do this, to many folks, is to universally ban it. If you start making tests to allow some and not others, you will get lawsuits of descrimination, racial profiling, and all of those similar garbage things.
Not only that, but how would you enforce the law? Stop everyone and see if they are allowed? or simply not stop anyone for it unless there is another reason (speeding/wreck/suspicion of chemical influence/etc).