Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?
Hi! Your vision on DOS is somewhat, well, interesting ;-) So there is a lot to chat about, although I am not sure if the KERNEL list is the right place for this topic. DPMI: I would expect performance gain to be minimal. Maybe there could be Low/HMA/UMB memory savings with a different architecture. Hard to say. Well there could, but why would it matter? More heavy DOS software normally uses DOS extenders / DPMI anyway, which means it does not care about how much low DOS RAM is free. The HMA is mostly used for the kernel and buffers, so as long as the kernel fits in there, no others have a heavy need for it. Only a few drivers may use it UMB style. Also, caches put bigger buffers in XMS, not needing HMA. Finally UMB is mostly used for drivers: You could write drivers that use DOS extenders / DPMI if you really have a lack of space. Actually the simulation of SoundBlaster 16 that comes with SoundBlaster PCI works like that. Probably also some commercial NTFS drivers, because NTFS is complex and you do not want to spend 100s of kilobytes of DOS memory only for loading a filesystem driver... USB, PXE and CD/DVD/BD drivers as drivers / in memdisk: I lean this way too w/respect to drivers. Built-in's biggest advantage is You still have to configure built-in drivers, you only avoid the risk that you forget to include the file in your boot disk ;-) simplicity in user configuration. However, networking seems to be lacking throughput speed with either mTCP or Watt32 apps. I'm not sure if it's a packet driver, TCP/IP stack, app (doubt), or kernel (doubt) issue. Networking in DOS means that your app has a compiled-in network stack which communicates with a packet driver to get the low-level hardware stuff done. You often have a small buffer for that and little concurrency. There may be a bit of IRQ and DMA, but big operating systems are more relaxed about juggling with multiple streams of net data with support from complex chips on your network card. Note that this is just an educated guess: Ask our experts! guess is that it's a 16-bit MOV/LD* loops, the lack of zero-copy networking, and the switch between kernel and app. I've seen some No switch: The kernel does not network at all and there is only one app at a time using the network. Depending on how your packet driver and network stack library work, you do not need many steps of copying either and the transfer to or from a buffer is unlikely to be a big bottleneck with modern CPU, I think. However, as said, you probably work with little bits of data and small buffers in DOS, because you may have less orchestration between stack and driver. reference to the same ... USB drivers as well (USB 1.1 speed from USB 2.0 devices or 3.0 devices). And there seems to be 3 ways to get USB That problem far much more trivial than you might think: USB 2 and 3 are controlled in ways that differ a lot from USB 1, so many drivers simply do not talk USB 2 or 3 at all. This is not like AGP, PCI or PCIe where you flip a few bits and suddenly I/O to your graphics card is fast. It is more like the difference between paged graphics at a000:0 and a linear framebuffer, to stay in the example. However, there is no linear USB. Talking USB the 2 or 3 way is just a quite different language, but as you know, at least one shareware driver speaks it and knows the dialect of at least some relatively widespread chips... working on DOS: USBDOS, DOSUSB, Panasonic/ASPI Method. I need to play Enjoy :-) And maybe do some benchmarks. Even the shareware driver should work long enough for that - I think it just blocks after a while after each boot, but is not locked in terms of how many days or years you have it installed. On the other hand, I think it would be an interesting experiment to have a kernel which can load files from at least the root dir of ISO9660 or UDF disks and similar (ext2? ntfs?) and which can directly interpret GPT partition tables... Yes! I agree! The FD Kernel needs to speak MBR, GPT, ISO9660 UDF (including El Torito), NTFS, Ext2/3/4 to stay relevant. Probably HFS+ as well. Linux and/or FUSE should be helpful here. Uhm no. You do not agree ;-) Yes the kernel should speak both MBR and GPT. Something about 4k sector size is also a good idea. However, El Torito is only so-so as CD/DVD/BD driver and Jack's drivers are probably better. It would be fun from an academic point of view to have ElTorito-ISO9660-GPT in a kernel, but even Linux works great with kernels-without-any- disk-drivers when you put the drivers in the boot-ramdisk to load them as separate files from there. DOS with MEMDISK is basically the same. Having (separately loaded) drivers for ISO9660 (we do, even with long file name support) and UDF (only experimental and abandoned??) is indeed important for DOS. Also, somebody may want to undust the old EXT2 semi-drivers called LTOOLS, they probably still have some sort of ancient limitation such as lacking LBA support or getting
Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?
Hi Louis, sort of a long response - it seems hard to make a short point here: FreeDOS Roadmap, as goals and stretch goals for the project. I read (paraphrasing): built-in networking, built-in USB, integrated DPMI, 32-bit The fd32 project works or worked on the DPMI aspect. As far as I remember, the performance gain was minimal, but consider interest in terms of style to consider a protected mode kernel which has both DPMI and VM86 visibility. It would be a sort of DOSBOX then. Regarding built-in networking and USB, I am personally more for the existing loadable driver model. The BIOS gives you enough support to reach the point where you can load drivers in config sys. Even when booting via network (PXE) or from CD/DVD/BD, you can still use a MEMDISK (bootable ramdisk) to get started... On the other hand, I think it would be an interesting experiment to have a kernel which can load files from at least the root dir of ISO9660 or UDF disks and similar (ext2? ntfs?) and which can directly interpret GPT partition tables. The latter would have significant practical use. Not the former: When you boot from CD/DVD/BD, you do typically want a writeable ramdisk anyway, so you can just as well boot with the help of a MEMDISK which lets you load DOS CD/... drivers from there, making drivers for that as fixed parts of the kernel less interesting. Also, they are harder to update than separate drivers and you cannot easily skip them at boot to save DOS memory. Good question whether you want built-in USB: I would say no, you already need the BIOS to help to boot from USB. After that, you want a modular system of USB drivers (unless the BIOS provides support for all relevant USB devices) to let you access disks, sticks, mice, keyboards and so on. Also, devices for which there is no popular DOS or BIOS interface, such as network or sound, cannot have kernel drivers in a useful way. For networking, the packet driver interface is just one facet in a complex world, we could think about some additions to make it easier to write new drivers or to do common things with the network. For sound, the lack of popular interfaces means that you basically have to use protected mode to simulate a popular HARDWARE (SoundBlaster etc) and then let your actual driver play whatever the soundblaster would have played given the detected I/O with the simulation. 64-bit support, device driver imports, automated regression testing. Some automated or semi-automatic quality checks seem interesting. One could think of code style checks, audits, automated comparison of how well different artificial test cases or real software runs work with different kernel (micro-) versions in some VM etcetera. Regarding 64 bit support, there are some experiments with letting DPMI drivers use more than 4 GB of RAM. To make better use of it, you would have to define new interfaces (XMS, EMS, DPMI, VCPI...) and hope that DOS software would be written which uses them. Just using 32- or 64-bit calculations (not RAM addresses) is another story: Probably the kernel can be smaller by using more 32-bit calc but not really faster. Using memcopy optimized for more modern CPU (32, 64, 128, ... bit, FPU, MMX, SSE, ...) will also not make a real difference, as the DOS kernel itself does not move a lot of data. In short, there are certainly points in which DOS can be extended, but I personally doubt that many or even any of them should start in the kernel. Separate drivers and other software fit better. Maybe we should discuss the roadmap again in the first place? Regards, Eric -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?
On 03/05/2013 15:55, Tom Ehlert wrote: In the past, we compiled kernels for 8086, 186 and 386 separately afair. I guess we got lazy and have dropped 186 because very few users have 186/286 as their CPU? They either have modern or REALLY old. this is not about 'lazy' it's easier for the user to select between 2 choices then between 4. multiply by 2 (FAT16/FAT32), this is 4 or 8 kernels. there's not much use for a 186 kernel as NOBODY has 186/286 machines these days, Really, NOBODY. Hans www.ht-lab.com -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?
Haha...I'd be interested if you ever developed a 586 core at 1GHz that could utilize DDR-3 upto 4GB. On Sat, May 4, 2013 at 1:43 AM, ht-lab han...@ht-lab.com wrote: On 03/05/2013 15:55, Tom Ehlert wrote: In the past, we compiled kernels for 8086, 186 and 386 separately afair. I guess we got lazy and have dropped 186 because very few users have 186/286 as their CPU? They either have modern or REALLY old. this is not about 'lazy' it's easier for the user to select between 2 choices then between 4. multiply by 2 (FAT16/FAT32), this is 4 or 8 kernels. there's not much use for a 186 kernel as NOBODY has 186/286 machines these days, Really, NOBODY. Hans www.ht-lab.com -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?
On Fri, May 3, 2013 at 4:02 AM, Eric Auer e.a...@jpberlin.de wrote: Hi Louis, if I understand your patch correctly, you only changed the build configuration to check how it affects the size of the compiled kernel before UPX compression, which also is an indicator of RAM size of the kernel? You changed the config.b, build.bat, buildall.bat files and generic.mak and watcom.mak and the resulting kernel sizes give the impression that in fact you only have FOUR distinct CPU optimizations, rather than seven cases... Yes. And just ran md5sum's against the kernels to verify this 3c0d2507d2595727b6d9a9a1bc979e72 kwc8616.sys 40d4679c99cd2579d0a96acdaaa62d99 kwc18616.sys 2234e5d367fb2562f430bc84dafd5c7d kwc28616.sys 623498bd71a46d16bcef211e743a9bed kwc38616.sys c3a607792ba8a0c8c8705dd370180619 kwc48616.sys c3a607792ba8a0c8c8705dd370180619 kwc58616.sys c3a607792ba8a0c8c8705dd370180619 kwc68616.sys 69eb7732f791db340632f722c9dbce16 kwc8632.sys f5c6d0d778fb196610385bc7c4689419 kwc18632.sys 1e4fd656603fd09171d9d85631e77045 kwc28632.sys b51d670433fd5d0d31d7babecbed84fe kwc38632.sys e1e87c09787ea3db18ccaa5c1675420a kwc48632.sys e1e87c09787ea3db18ccaa5c1675420a kwc58632.sys e1e87c09787ea3db18ccaa5c1675420a kwc68632.sys ...and I'll modify Eric's assertion. There's 5 kernel produced by OW for the 7 arch's. x86, 186, 286, 386, 486+. It would seem that OW doesn't know much about 586+ arch's but can use the instructions in special situations. And this makes sense when you consider when Watcom fell out of favor commercially and probably saw it's last real optimizer work. Kernels without FAT32: 086: 64158 bytes 186: 63028 bytes (286 same) 386: 62164 bytes 486: 62068 bytes (586 and 686 same) Kernels with FAT32: 086: 68358 bytes 186: 67180 bytes (286 same) 386: 66044 bytes 486: 65948 bytes (586 and 686 same) [SNIP] Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm in the kernel now and possibly the string functions. But just an idea right now. -L -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?
What's the difference between wcc wcc386? I noticed that wcc386 adds -5s, -5r, -fp5 (-6 equivalents) for stack, register and fpu optimization. Does wcc386 generate code that could be used in the kernel? -L On Fri, May 3, 2013 at 5:57 AM, Louis Santillan lpsan...@gmail.com wrote: On Fri, May 3, 2013 at 4:02 AM, Eric Auer e.a...@jpberlin.de wrote: Hi Louis, if I understand your patch correctly, you only changed the build configuration to check how it affects the size of the compiled kernel before UPX compression, which also is an indicator of RAM size of the kernel? You changed the config.b, build.bat, buildall.bat files and generic.mak and watcom.mak and the resulting kernel sizes give the impression that in fact you only have FOUR distinct CPU optimizations, rather than seven cases... Yes. And just ran md5sum's against the kernels to verify this 3c0d2507d2595727b6d9a9a1bc979e72 kwc8616.sys 40d4679c99cd2579d0a96acdaaa62d99 kwc18616.sys 2234e5d367fb2562f430bc84dafd5c7d kwc28616.sys 623498bd71a46d16bcef211e743a9bed kwc38616.sys c3a607792ba8a0c8c8705dd370180619 kwc48616.sys c3a607792ba8a0c8c8705dd370180619 kwc58616.sys c3a607792ba8a0c8c8705dd370180619 kwc68616.sys 69eb7732f791db340632f722c9dbce16 kwc8632.sys f5c6d0d778fb196610385bc7c4689419 kwc18632.sys 1e4fd656603fd09171d9d85631e77045 kwc28632.sys b51d670433fd5d0d31d7babecbed84fe kwc38632.sys e1e87c09787ea3db18ccaa5c1675420a kwc48632.sys e1e87c09787ea3db18ccaa5c1675420a kwc58632.sys e1e87c09787ea3db18ccaa5c1675420a kwc68632.sys ...and I'll modify Eric's assertion. There's 5 kernel produced by OW for the 7 arch's. x86, 186, 286, 386, 486+. It would seem that OW doesn't know much about 586+ arch's but can use the instructions in special situations. And this makes sense when you consider when Watcom fell out of favor commercially and probably saw it's last real optimizer work. Kernels without FAT32: 086: 64158 bytes 186: 63028 bytes (286 same) 386: 62164 bytes 486: 62068 bytes (586 and 686 same) Kernels with FAT32: 086: 68358 bytes 186: 67180 bytes (286 same) 386: 66044 bytes 486: 65948 bytes (586 and 686 same) [SNIP] Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm in the kernel now and possibly the string functions. But just an idea right now. -L -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?
Kernels with FAT32: 086: 68358 bytes 186: 67180 bytes (286 same) 386: 66044 bytes 486: 65948 bytes (586 and 686 same) It is interesting that even 186 instructions do make a quite big difference and that there is a difference at all between 386 and 486. With 186, you get pusha and popa, shift/rotate by fixed numbers of bits. ENTER LEAVE In the past, we compiled kernels for 8086, 186 and 386 separately afair. I guess we got lazy and have dropped 186 because very few users have 186/286 as their CPU? They either have modern or REALLY old. this is not about 'lazy' it's easier for the user to select between 2 choices then between 4. multiply by 2 (FAT16/FAT32), this is 4 or 8 kernels. there's not much use for a 186 kernel as NOBODY has 186/286 machines these days, Also, we keep offering 8086 compiles for the sake of good old times and for people with emulators. The 386 optimization is useful and we already used it: Having 32 bit computations helps even for DOS. There are also some new bit string opcodes, SETCC (conditional set a byte) nothing of this is used by the compiler JCXZ was always supported and near conditional jumps and loops that are supported starting at 386. *far* conditional jumps started with 386. however what *IS* used by wcc is the additional FS and GS register some (few) push DWORD constant what would be useful, but is not used by WCC dword arithmetic filesystem code uses long variables everywhere Your 486 to 686 kernels are the same size and 486s only XADD and BSWAP (and CMPXCHG). It is impressive that those actually make any (100 byte) difference! strange enough, compiling here with -3 and -6 makes exactly no difference. using watcom 1.9 could you post the compiled files, or even for %i in (*.obj) do wdis -l -a -s %i for -3 and -6 and show us the differences ? Maybe your compiles assume that 486 does and 386 does not have FPU? That would not be very accurate. pointless as the kernel doesn't use any FPU code As with 286, the news in 586 is mostly protected mode related (simply speaking). Neither CMPXCHG8B nor the time stamp counter nor CPUID bothers DOS. The main news in 686 would be CMOV, a conditional MOV, but looking only at kernel sizes, it is likely that the compiler just does not use CMOV for 686. It is odd to get exactly the same size otherwise. it doesn't use cmov For even newer CPU, you could use FPU and vector (MMX, SSE, SSE2, SSE3, SSE4a, EMMX, 3dNow, 3dNow+, SSE4.1, SSE4.2, AVX FMA, not AES ;-)) instructions but it is highly unlikely that those make any DOS difference. At most they could speed up memmove. as the kernel doesn't much memcpy/memmove, you can't accelerate it by any significant amount.otherwise we *would* have rep movsD tom -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?
What's the difference between wcc wcc386? code generation for 16 bit (DOS) or 32 bit (windows) Does wcc386 generate code that could be used in the kernel? no Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm in the kernel now and possibly the string functions. But just an idea right now. the kernel doesn't copy (much). nothing to be gained. tom -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
