Nice question. I almost got it wrong, because I had first overlooked the TOP clause.
However, the official correct answer is still a bit questionable. The result of a TOP without ORDER BY is officially undocumented and undefined. It is true that all combinations of SQL Server version and hardware you and I and others have tested this on always produce the same execution plan, and hence the same result. But from that you cannot infer that this is guaranteed behaviour. For all we know, there may be a critical hotfix being pushed out through Windows Update right now that changes this behaviour.
I know this may seem nitpickish, as this would be an extremely unlikely change, but I think it's really important for everyone to know that they should never rely on undocumented behaviour, no matter how repeatable and how safe it appears. People have been bitten by trusting undocumented behaviour (*), and I'm afraid that this will continue.
(*) The two best examples of this that I recall are:
(1) The introduction of new queryplan operators for grouping, I think in SQL 7.0. Before that, sorting was the only option for the optimizer, and many people wrote their group by queries without order by clause. Big surprise for them when, after upgrade, the optimizer suddenly chose to do a hash group by!
(2) The optimizer change that caused "TOP 100 PERCENT" to be ignored (wasn't that in SQL 2005?), breaking code for people who had added that and an ORDER BY clause to their view, thinking that they now didn't need to have an ORDER BY in their queries anymore. And to my utter amazement, people who ahve been bitten by this still insist on "fixing" this with just a different undocumented "trick". And to my even utterer (is that a word?) amazement, Microsoft's own tool -the view designer in SSMS!- still generates this non-working clause, even in SQL Server 2012 (though it now does pop up a warning message when you try to save the view, a slight improvement over 2008R2).