Pages: 1 2 [3]   Go Down
Author Topic: A mini with a Ferrari's Engine? lol  (Read 2218 times)
0 Members and 1 Guest are viewing this topic.
Valencia, Spain
Offline Offline
Faraday Member
**
Karma: 150
Posts: 5677
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

...this allows loading code from ram for execution in flash. this is what  all bootloaders do. so you can argue about what constitutes harvard but the fact remains code from ee or ram CAN be executed. its mostly a timing issue.

By that defnition a computer can execute code stored anywhere.

The C64 demo in question was placing code in I/O registers of the chips (the control registers of a timer) and executing it from there. Hardly the same as the game of semantics you're trying to get us to play.

afaik no one has been able to do this in windows since 98.

Windows 98 is preemptive.

Maybe you're thinking of Windows 3.1 running in unprotected mode on a 286.

and btw c girls should not even try due to opcode timing issues usually associated with compiled code. at least with gcc from what i can tell. maybe inline asm tricks but i doubt it.

That's not the reason why Linux isn't a real-time OS.

It doesn't matter what the opcode timings are if another thread (or interrupt) can come along and take over the CPU  half way though your critical loop.

Logged

No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

Anchorage, AK
Offline Offline
Edison Member
*
Karma: 42
Posts: 1176
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

OK, I disagree where you draw the lines between architectures and OS process execution theories, but you've proven you have some technical basis for your opinion, and with that earned respect.  I take back the troll comment.

I think we're arguing semantics at this point.  Whether any modern Linux kernel allows you to assume indefinite control of the processor is not so much a matter of skill and RTOS-like functionality.  Afterall, a driver (executed at or near the level of privilege that the kernel itself enjoys) will behave like this to some extent.  But, the contract you as a developer have with your operating system would forbid you to do so from an application context on a cooperative kernel, whereas it's assumed you'll do this on a RTOS kernel.

Windows drivers can spinlock a CPU as well, so I'm not sure this is a uniquely Linux thing, but I'm not a kernel hacker or driver developer either.  Is there anything in the kernel that prevents execution of particular opcodes on either platform, once you're in kernel-land?  It was my assumption that code at that level was free to do just about anything it wants to, which is what makes bugs (and especially malicious code!) there so vile.
Logged

vermont
Offline Offline
Sr. Member
****
Karma: 8
Posts: 316
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

ill concede avr does not comply fully with common definitions of von neuman so admit to a little trolling but technically ee and ram data inside the CHIP can be executed after a fashion. when these architectures were defined back in the 40s i doubt they resembled any of the modern mcu addressing modes and features available today. so i dont consider avr to fit perfectly into either category, but we must agree there is no problem reading data in the code space so lets call it "von harvard" for now. smiley

for the protected mode subject i based comments on what people have actually managed to do in the past. i think a lot may depend on linux having source available and windoze not. also i was left in the dust years ago on kernal technology and pc core hardware so not really sure whats going on these days.

it was an interesting discussion though.

« Last Edit: October 18, 2013, 05:14:23 pm by john1993 » Logged

Valencia, Spain
Offline Offline
Faraday Member
**
Karma: 150
Posts: 5677
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Windows drivers can spinlock a CPU as well, so I'm not sure this is a uniquely Linux thing, but I'm not a kernel hacker or driver developer either.  Is there anything in the kernel that prevents execution of particular opcodes on either platform, once you're in kernel-land?  It was my assumption that code at that level was free to do just about anything it wants to, which is what makes bugs (and especially malicious code!) there so vile.

Modern CPUs have watchdogs and non-maskable interrupts to try and get control back. That's how blue screens of death, etc., work. You could cause a machine shutdown if the OS detects you trying to prevent multitasking.

I'm sure Linux allows you to disable this, too, but at that point you're left with an almost useless machine - you wan't be able to read disks or anything like that.

The only way to get genuine realtime performance is to dedicate a non-interruptable CPU to each critical task, eg. a load of Arduinos attached to a Linux machine.
Logged

No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 137
Posts: 6792
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Note that "real time operating system" usually refers to a OS (and programming style) capable of providing deterministic response to events WITHIN REASONABLE LIMITS.  Frequently, rather "slow" limits.  So there are operating system that are considered "hard real time", but are still preemptive and much slower than dedicated hardware.  Windows and Linux are NOT "real time" operating systems in that sense, but can still be made to provide adequate performance for many time-critical or performance-critical tasks.
(Meanwhile, the "real" RTOSes frequently achieve their latency guarantees by sacrificing overall performance.)

For instance, back in the early days of the internet, there was a glowing report from BBN on how their "butterfly gateway" could guarantee that a packet would be switched within 1ms of arrival.  Over at cisco, we shrugged this off; we were (at that time) switching over 10000pps, which we thought was a lot better.  I still think it was a lot better; but I had missed the point.  We were only doing 10000pps MOST of the time.  Assuring less than 1ms switching time for ALL packets was a harder problem!  (although, perhaps not as useful to solve...)
Logged

Pages: 1 2 [3]   Go Up
Jump to: