28 Jun
2020
28 Jun
'20
7:32 p.m.
For the various flow control works, Forth generally teaches you to not spread flow control
across multiple pages. Unless you are really trying to reach for every last clock cycle,
it makes sense to factor even assembly code. It makes understanding the code easier and
allows one to think about what is happening in the code.
Of course, good choices of names make sense. One can even make a page long macro to paste
in-line a block of code for a zero cycle cost factoring.
Factoring is the key to such things. A page of straight assembly is a bad idea in the
first place.
I don't see creating labels spread across several pages any better then doing good
factoring.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of ben via cctalk
<cctalk at classiccmp.org>
Sent: Sunday, June 28, 2020 5:32 PM
To: cctalk at classiccmp.org <cctalk at classiccmp.org>
Subject: Re: On: raising the semantic level of a program
On 6/28/2020 5:20 PM, Peter Corlett via cctalk wrote:
DISC I/O seems to have stage packed formats of bytes shorts and longs
all packed a character array. Directory structures or inodes come to mind.
The x86 is broken period.
'int' size depends on the compiler making porting programs interesting,
as well as macro processor and make files.
Ben.
On Sun, Jun 28, 2020 at 01:32:02PM -0700, Chuck Guzis
via cctalk wrote:
[...]
Just what is a NON broken string design?
Why is byte-granularity in addressing a
necessity?
Because C's strings are broken by design and require one to be able to form a
pointer to individual characters.
It's only
an issue if you have instructions that operate directly on byte
quantities in memory.
One wheeze is to just declare that bytes are the same size as a machine word. C
doesn't require char to be exactly 8 bits, but merely at least 8 bits. However,
a lot of C code will break if char, short, int and long aren't exactly the same
size as they are on x86. Mind you, a lot of it is still broken even if they
are...