Subject:
|
Re: Perl rules!
|
Newsgroups:
|
lugnet.off-topic.geek
|
Date:
|
Thu, 22 Jul 1999 16:11:41 GMT
|
Viewed:
|
1126 times
|
| |
|
|
In lugnet.off-topic.geek, Steve Bliss writes:
> On Wed, 21 Jul 1999 23:43:27 GMT, "Don Heyse"
> <donnell_heyse@adc.spam.go.away.com> wrote:
>
> > In lugnet.off-topic.geek, Steve Bliss writes:
> > > How did the segmented architecture enable the creation of tiny programs?
> >
> > Relative pointers in the same segment take up half as much space as a 32
> > bit pointer. Depending on what you're doing, the savings here can be
> > considerable. .COM programs used nothing but relative pointers and fit
> > in less than 1 64K segment.
>
> OK, relative-addressing mode is good. But it doesn't require segmented
> memory. All it requires is an instruction format with a defined result.
>
> For example, the conditional-jump instructions on the 6502
> microprocessor[1] only used relative addressing. You could only jump in
> the range of -128 to +127 bytes. So all the conditional jump instructions
> took two bytes: one for the opcode, and another for the offset. But there
> was no segmented memory addressing.
Perhaps you're right, but that jump instruction is relative to the Instruction
Pointer which uses a full register. The segmented way you are relative
to a segment which only uses half a register. You can take advantage of
this half register use for considerable savings. Just don't ask me how cause
I forgot.
>
> > That's tiny in my book. Nowadays, tiny
> > rarely fits on a 1.44 meg floppy. Also the trend toward RISC architecture
> > leads to code bloat for a lot of reasons that I'd have to look up. It's
> > been a while since I thought about it. I sorta gave in and joined the
> > bloat crew.
>
> I know what you mean--I program in Visual Bloat.
>
> > > > > Yeah, but what does that have to do with LDraw not supporting modes with
> > > > > more than 4-bit color?
> > > >
> > > > Isn't 4 bit color the lowest common denominator between VGA and EGA?
> > >
> > > So? This is SVGA, and most video cards seem to not offer 4-bit color modes
> > > in resolutions above 800x600. So LDraw will happily work in modes that
> > > most video cards can't deal with, and LDraw won't do modes that video cards
> > > will.
> >
> > Perhaps the original drivers were written to support only standard VGA and
> > EGA and then were extended to support SVGA in compatible modes only.
> > 640x480 x 4bits per pixel fits in one of those 64K segments and thus supports
> > tighter code (A feature at the time)
>
> But it wouldn't have cost LDraw much (if anything) to support higher
> color-depths. It would just need to be able to talk to the library driving
> the display. It wouldn't have to hold the higher-color bitmap itself.
There are other issues here. 4bits per pixel uses lookup tables to pick
colors. You can do tricks with XORing colors to move things around without
redrawing everything. I'm sure this was taken advantage of. Perhaps this
is why moving the pieces with the keys seems so responsive.
> > Hey, does LEDIT support any resolution other than 640x480?
>
> Nope. WYSIWYG.[2]
Rats!
> > It seems more
> > responsive to keystokes than LDAO/LDLITE right now, so I can work faster.
>
> That's very true. I do much more parts-authoring than modeling, so I
> mostly use LDAO/LDLITE. I need to look more at mlcad, to see if I can make
> parts in that program...
I would like LDAO/LDLITE better if the moving piece was drawn first, then
the rest of the picture. I don't think the version I have works that way.
About half of the time I don't even want to see the rest of the model.
You can take these comments with a grain of salt. I've only done one model
so far so my opinions are subject to change as I gain experience.
>
> > (I do like to ALT tab to the VEC though :-)) If only netscape had an all
> > keyboard interface...
>
> Doesn't it suck when programs don't have complete support from the
> keyboard?[3] Especially high-cost development tools[4], with the layers of
> dialog boxes that you constantly have to pop in and out of.
Yes! Yes! Yes! The keyboard is a much more efficient tool than the mouse.
You don't have to aim. This is one reason I stick with EMACS even though
it's huge. Your fingers never leave the keyboard.
> Steve
> --
> 1- The 6502 architecture and instruction set is the only assembly/machine
> language environment I can claim to be conversant in.
> 2- WYSIWYG in the classic retail-sales sense, not in the desktop publishing
> sense.
> 3- LDAO is guilty of this, I think. In the VEC, you can't select a part,
> so you can't access the functions of the context menu except by
> right-clicking the mouse on the part.
> 4- Power Designer and DSSArchitect are two that spring to mind.
|
|
Message is in Reply To:
 | | Re: Perl rules!
|
| (...) OK, relative-addressing mode is good. But it doesn't require segmented memory. All it requires is an instruction format with a defined result. For example, the conditional-jump instructions on the 6502 microprocessor[1] only used relative (...) (25 years ago, 22-Jul-99, to lugnet.off-topic.geek)
|
433 Messages in This Thread:
(Inline display suppressed due to large size. Click Dots below to view.)
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
