So: Anti software bloat
in [Design]
|
From: Tim Williams on 21 May 2010 20:55 "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote in message news:FEEJn.152195$pj7.115220(a)en-nntp-15.dc1.easynews.com... >> Very few operations used IN/OUT. The display was memory mapped. > > Oh yeah, my mistake -- I was just remembering that you had your choise of > "really slow text output" on the old CGA cards or "fast but with snow." > But that was due to there being no mechanism to deal with the CPU and > video controller both accessing video memory at once (well, other than > "CPU must win for the sake of data integrity, it's OK if it snows a bit on > the screen"), not IN/OUT commands. Funny, the Paradise EGA chip in my Amstrad (w00t, 256kB EGA in an IBM compatible!) blocks memory access during scans. The processor only gets to play for a few microseconds during horizontal refresh, and a miliseond during vertical. But it has its own RAM (no parity, of course), attached to the peripheral bus, accessible by the processor, so it doesn't hold up programs or I/O unless addressed. EGA is quite slow if you want to update a 640x350 screen, touching every pixel will easily take a second to complete. Longer if you try doing it in QBasic. :-p However, using the EGA hardware to emulate scrolling, while drawing sprites in 320x200, was the step that enabled the first live action video game on the PC. There aren't all that many IO-intensive things to do. Switching graphics modes writes to every single register on the adapter once (sometimes twice). Time constants in the monitor's sweep limit any need of this going fast. Palette animation on VGA is a bit tedious, because you have to update 768 bytes of palette registers at once. But VGA machines are a bit faster, and a palette refresh might be done during vertical refresh only, so it's also not a big deal. I don't know enough about HDD access to say if it involves IO. I suppose there are interrupts involved, and a buffer and DMA, at least on the DMA-supporting cards (IDE+?). I suppose an old MFM/RLL drive may not be fast enough to really require DMA anyway. > And I guess the BIOS text routines were slow as well, right? -- Everyone > just bypassed them, writing directly to video memory, after a little bit? Oh, very much so. The graphics routines sucked, too. It's SOP to take the video hardware by the balls if you're doing anything speedy in DOS. Just for the hell of it, I once wrote a buffered mode 13h graphics routine, then decided to run it in EGA... so I made a buffer converter to strip 256 colors down to 16, divide into bitplanes and copy it to the video RAM. Actually runs pretty good on modern hardware, takes a second or two on the vintage hardware though! Tim -- Deep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms
From: krw on 21 May 2010 23:09 On Fri, 21 May 2010 16:26:26 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: ><krw(a)att.bizzzzzzzzzzzz> wrote in message >news:vk4ev59cr98vv1m0dtuls2letu6bi44q6f(a)4ax.com... >> Very few operations used IN/OUT. The display was memory mapped. > >Oh yeah, my mistake -- I was just remembering that you had your choise of >"really slow text output" on the old CGA cards or "fast but with snow." But >that was due to there being no mechanism to deal with the CPU and video >controller both accessing video memory at once (well, other than "CPU must win >for the sake of data integrity, it's OK if it snows a bit on the screen"), not >IN/OUT commands. Sure there was a mechanism; "don't do that!". Just wait for the retrace before you touch memory. Not a good mechanism, but there was a mechanism. ;-) >And I guess the BIOS text routines were slow as well, right? -- Everyone just >bypassed them, writing directly to video memory, after a little bit? Sure. The BIOS routines were meant for console mode I/O, where speed didn't really matter much. >I kinda suspect that for business users the Apple IIgs might have won out over >PCs if it'd been released a few years earlier. Not likely. >Or maybe not -- perhaps the >availability of clones is what really put PCs on top... and I suppose Apple >was competing with itself as well, having released the Macintosh prior to the >IIgs. Absolutely. There was nothing special about PCs, other than everyone made them and they all worked, more or less. Good enough, anyway. >What computers did you have before PCs took over the world, Keith? :-) The first systems I used were /360s, a /75 in college and then a boatload of /85s at work, though the bubble gum and bailing wire was getting tired on them by '78 or so. They were pretty much junk to begin with[*]. Interesting story about Intel memory on those things. IBM had never used Intel products but since the corporate purchasing group was in the Hudson Valley Intel placed their NE rep in Poughkeepsie. One day he gets a PO for $100M in memory. The memory was never seen again and all the industry rags were wondering where it went. Well, those /85s got brand new memory, their memory got ETNed and shipped with new machines. The power supplies were hacked in and if there was going to be a failure, our engineering people were going to be the ones to suck it up. Oh, since they had never done any significant business with IBM, the Intel rep had a 1% commission deal as a small incentive. They wanted to renegotiate, "fine, we can negotiate next years, anytime you want." [*] recalled from customers because they had unsolvable metastability problems.
From: Robert Baer on 21 May 2010 23:09 Jan Panteltje wrote: > I just wrote a program for a Microchip PIC 18F14K22 microcontroller > driving a ENC28J60 Ethernet controller in ASM. > Because this PIC's SPI interface does not work in I bitbanged it,,, > As this PIC has only 256 bytes of RAM..... > > So far so good... But what does it do??? > Well many things, but one of it is that it (oh it has a MAX232 too, ye know a MAXIM chip, I have some, > the rumour that those do not exist is false, but you do not need the MAXIM chip you > can do it with a NPN transistor and diode), > so: > It streams the serial port to UDP worldwide, sort of internet radio. > At 115200 Bd it just about can send a 64 kbps mp3 worldwide, and you can just hang > a player on it (xine, mplayer, ffplay, whatever, best something with a cache or buffer). > > 115200 Bd is 11520 bytes / second (1 start, 8 data, 1 stop bit), or 92,160 bits / second > Add overhead for IP and UDP header... there you are: 64 kbps. > Small packets, using a dual buffer in the 256 bytes RAM, while writing via > serial interrupt, sending the other buffer via bitbang SPI to the ethernet controller. > > So how big is it? > Well with my own designed UDP stack: just about 10000 bytes. > Yes 10 KILOBYTES. > > What more can it do? > Oh I added about 2 kilobytes so it can also be used in 'listen' mode, > and you can remotely set 2 digital outputs, read 2 digital inputs, read 4 analog 10 bit channels, and set 1 PWM output. > For that you need no serial interface at all.. > Of all that code size more then 10 % is test routines. > Text takes a lot of space. > So what OS? > No OS. > Total parts cost of the unit about 10 $ in small quantities. > > Who needs a 'computah' for remote telemetry :-) > What 'bloat'? > > Now there is free code space, free code space free code space, whatshallwedo with the free code space? > I have some idea. > > If you are to compete with M$, you _must_ have software bloat!!! The more bloat, the better the competition!
From: Paul Keinanen on 22 May 2010 03:44 On Fri, 21 May 2010 06:29:43 -0700 (PDT), MooseFET <kensmith(a)rahul.net> wrote: >On May 20, 8:10�pm, D Yuniskis <not.going.to...(a)seen.com> wrote: >> MooseFET wrote: >> > On May 20, 9:59 am, D Yuniskis <not.going.to...(a)seen.com> wrote: >> > [...] >> >> And I could never wrap my head around the i432. �Just too "radical" >> >> for my sensibilities (at the time), I guess... �:< >> >> > Each instruction of the 432 was basically like this: >> >> > � if (I am allowed to) Memory[AddressingTable[i]] >> > � � � � � � � � = Memory[AddressingTable[j]] >> > � � � � � � � � + Memory[AddressingTable[k]] >> >> > There was no way to directly address the memory. �The machine always >> > had to take the time to look up the address where the object was and >> > check to see if this instruction is allowed on this instruction. >> >> Yes, they tried to make everything an "object". �It was too >> wacky thinking for the time. �I suspect it would still be too >> inefficient even with today['s technology. Current virtual memory machines have dedicated translation buffers, these TLBs work just like caches. In normal operation, most virtual to physical address translations are done in TLBs and only occasionally there would be a miss and a new table partition needs to be loaded from main memory. In the same way, the i432 addressing could work quite effectively these days. With suitable caching, the TMS9900 style "register set in memory" would also quite effective these days.
From: Paul Keinanen on 22 May 2010 04:37
On Fri, 21 May 2010 09:41:34 +0100, Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote: > For security I favour Harvard architecture. >Complete separation of code and data spaces prevents a lot of common >forms of attack against system integrity. The 80386 had read, write and execute bits in the segment descriptor register, why did't they use these to limit the access to different segments ? In 386 and later models, the segment registers are still there (usually mapped from 0..4 GiB in an overlapped way), before going through the virtual to physical translation. >Flat linear address spaces >which are in vogue now may one day be seen as a very bad idea. Already in decent 70's virtual memory minicomputers, each virtual memory page had read, write and execute bits on a page by page basis. A large complex program running in a single huge address space can be a problem, if something is malfunctioning. However, now that people have learned how to write multithreaded programs, it should not be a huge leap for most programs to write truly multitasking programs, with each program running in a separate, protected address space. The communication can be handled with OS services or using shared memory areas to share that data that is meant to be shared and not everything. |