Segmentation in real mode
in [ASM]
|
Prev: stricmp
Next: Killing Explorer
From: /o//annabee on 13 Mar 2005 23:50 Pý Mon, 14 Mar 2005 04:16:42 GMT, skrev Beth <BethStone21(a)hotmail.NOSPICEDHAM.com>: > Rene wrote: >> Tom wrote: >> > I'll be fine learning more from you, Mr. Hyde. Thank you very much for >> > your kind interest. And thank you for Webster. >> >> Given the situation, whatever i could say would have >> no effect, but, just in case you would not be utterly >> stupid... >> >> Randall Hyde is the individual who actually the most >> damages Assembly. > > Rene Tournois is an individual who also has an assembler - RosAsm - that > isn't as popular as Randy's HLA... > > Enough said, yes? ;) > > Beth :) Btw, Beth, about your problem with Linux vs windows machine. Why not SWITCH ?? No you cant do that... cause you HATE LINUX. You need your little Windows gadgets. MSN and all the "goodies" that you have grown so attached too :))) Dont even try to deny it. You're much likly a M$ Owned property. -- I am shy
From: Dirk Wolfgang Glomp on 14 Mar 2005 04:14 Betov schrieb: > 2) Accessing the real HardWare is in no way "more > educational", at an Assembly point of view. To me, > actual Assembly, on actual Computer does not need > in any way to access the damned HardWare, unless > it would be for very specialized task, that are > completly out of the normal programmation scope, > and even more out of scope for a beginner. My normal programmation scope, is to access the graphic card directly with "no" limitation/access violation, in Big-(Un)Real-Mode. This is an easy way for beginner, to understand exactly the damned HardWare of a normal graphic card. I use the Vesa-Mode(vesa.org) to show a fraktal-picture. Any CPU is to slow to calc fraktals, so i need the completely power with no OS-overhead. Additonaly i hate to learn the specialized task of an OS, to do the same under Linux/Windows with no self-control the d.. HardWare. Dirk
From: Betov on 14 Mar 2005 06:31 Dirk Wolfgang Glomp <dirk(a)freecrac.dyndns.org> ýcrivait news:ufp31d.3k.ln(a)news.home.freecrac.dyndns.org: > Betov schrieb: >> 2) Accessing the real HardWare is in no way "more >> educational", at an Assembly point of view. To me, >> actual Assembly, on actual Computer does not need >> in any way to access the damned HardWare, unless >> it would be for very specialized task, that are >> completly out of the normal programmation scope, >> and even more out of scope for a beginner. > > My normal programmation scope, > is to access the graphic card directly > with "no" limitation/access violation, in Big-(Un)Real-Mode. > > This is an easy way for beginner, > to understand exactly the damned HardWare of a normal graphic card. > > I use the Vesa-Mode(vesa.org) to show a fraktal-picture. > Any CPU is to slow to calc fraktals, > so i need the completely power with no OS-overhead. > Additonaly i hate to learn the specialized task of an OS, > to do the same under Linux/Windows with no self-control the d.. HardWare. Well,... i wish you plain success for your futur Tutorials explaining to a beginner how to program his HardWare without OS. I also wish you plain success for having users using your Applications, runing without OS: This will be great news for me, as i will no more have to long for ReactOS to be ready to replace Windows. This will really be great: Even way better than MenuetOS. :)) :)) :)) Betov. < http://rosasm.org/ >
From: wolfgang kern on 13 Mar 2005 07:09 Hi Beth, | > Once Intel decided to make a CPU for larger memory than 64Kb, [Why and ... this "economic" factor] I think the segments were the first attempt for protection in terms of several .com-files and TSR's become isolated from the OS and each other by the PSP-pointers found in MCB's (Ok, they may overlap). Another point was for sure a memory management which doesn't waste too much bytes (like minimum 4Kb pages in windoze). So if segments would point to 64KB blocks by using upper bits only, the memory manager will need to keep track of offsets in addition. [backwards compatible] Right, we got to live with it... [PC vs. Mainframe] M$ and Intel tried to cover both with one machine, so the result is what we got: a permanent reason for ranting :) ["ring 0" and "ring 3"] My protection (mainly from my own bugs during code evaluation) have just main kernel including stack isolated by segmenting. External modules use flat code/data and use the stack to access 'globals' in th kernel's variable-block. ?? I never need a PL0 to PL0 transition (except RM <-> PM links). Ok, an OS which is made to execute code from unaware programmers/newbies and other buggy sources will be well advised to save itself by PL3 only. btw: try to debug/step into a winAPI, at least win98 seems to protect its ill data by page-attributs rather than PL-changes, seems all protection is performed through page-fault-exceptions, marked not present during user code runs :) What an ill idea. ["device drivers"] Why 'call' a routine, when I can use single byte instructions like IN/OUT INS/OUTS. I see this as a detouring timewaste. [task-switches] I see only two reasons for switching tasks: Debugger with an 'inter-mode' capability A stack fault. Both are not needed to run (my) application code. [time scheduling] | So, here's the simple idea: The scheduler has _dynamically-sized_ "time | slices"...whenever new process starts or a running process ends, the | scheduler then "adjusts" that "time slice" size so as to give each process | the CPU for the _maximum_ amount of time that it can, allowing for the need | for it to do a full "round robin" of all processes within a set period to | get that "optical illusion" thing going... That's exactly what I do, except I wont have 'processes' in HLL-means. My time slice works mainly on 1mS and work up to 20 jobs (50HZ view) in sequencial order (looks quite as parallel for the viewer). | Less task switching, longer uninterrupted runs of each process, better | cache use and so forth ... Yes. | You see what I'm doing here? We do our best to re-calculate the "optimal | task switch frequency" whenever a process starts or stops (which is, | comparatively speaking, an "infrequent event" :)...so, as to constantly and | dynamically try to keep the system's overall performance as "optimal" as | possible... This would mean the OS itself is a 'REAL-TIME-OS', KESYS is aware of time and code duration, windoze is a 'guess when' system, and I'm not sure Linux is designed any better ..., but it can be alterd ? :) | It's a kind of "compromise" idea between all the various "demands" ... Not a bad idea, but it may need some updates on the Linux kernel ... __ wolfgang
From: Beth on 16 Mar 2005 06:46
Annie wrote: > Beth wrote: > > Yep. > > Troll. So, why are you feeding me, then? Back into the "ignore file" you go: *plonk* Beth :) |