HLA v2.6 for FreeBSD is now available
Hi All, HLA v2.6 for FreeBSD is now available from the HLA download site on Webster: http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/HighLevelAsm/dnld.html v2.6 includes full PE/COFF native code generation for Win32, ELF native code generation for Linux and FreeBSD, and Mach-O native code generation for Mac OS X. v2.6 also implements a new overloads declaration for high-level-like procedure, method, and iterator calls. This is above and beyond the usual set of defect corrections. HLA is a high-level 32-bit x86 assembler that supports the 32-bit 80x86 instruction set as well as adding a set of high-level-like language features. More information on HLA is available at http://webster.cs.ucr.edu. Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
chdir/rmdir
Hi, I recently made a couple of calls like the following // currently in /x/y/z chdir( /x/y ); rmdir( /x/y/z ); When I did at gwd call, it returned /x/y/z along with ENOTDIR. Is this a known issue? I'm making low-level (assembly) calls via int 0x80 to do the above (not C stdlib), though I can't imagine that's causing the problem (then again, I've written broken code before :-(, this wouldn't be the first time I've messed up, though I have studied the code very closely and the same function calls work fine in other contexts). Thanks for any input, Randy Hyde P.S. I noticed that the man pages said something about using open on . and fchdir to more robustly switch back to some previous directory; this is what has me wondering if there is a problem with executing statements like the above. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HLA v1.100 is now available for FreeBSD
This looks like it might be interesting. Two comments: 1) Is there a FreeBSD port available? I assume you mean the PORTS distribution format. The answer is no, not yet. Someday I'll take the time to figure out how to do this (and RPMs or comparable things under Linux). In the meantime, all it really takes to install the guy is to unzip/tar it and set a couple of environment variables up. No big deal for most BSD/Linux users. OTOH, I do realize the benefit of having an installation program, so it's on the list of things to do. If there is an easy way to automate this in a make file (which I use to build by releases with), I'd be more than happy to include it when I release the next version; assuming someone is nice enough to show me how to do it. 2) Do you have any plans to target anything other than 80x86? HLA looks like it would be very handy as a development tool for embedded micros (PIC, Atmel etc). Long ago (pre-x86 Macintoshes) I was considering the PowerPC. That's history today, however. The ARM looks like fun, but The big goal I have right now is to get back to work on HLA v2.0 and get that generating code. For example, the port to the (x86) Macintosh has to wait for HLA v2.0 and getting a Mac OS X port operational is my next big task after HLA v2.0. Then, of course, the next most important thing is a port to the x86-64 (actually, HLA v2.0 contains the facilities for this, they just have to be activated). Then I can start looking at other processors. OTOH, the HLA compile-time language (i.e., macro language) is sufficiently powerful that you can actually *write* assemblers for other CPUs with the CTL. It would be slow compiling such programs, but it's certainly possible. And if you *really* want to move ahead with different CPUs today (I emphasize *you*, not *me*), I have posted the existing code for the HLA v2.0 compiler on Webster (http://webster.cs.ucr.edu/AsmTools/HLA/hla2/0_hla2.html). Currently, handling almost all of the declarations is complete (no machine instructions yet). So it's in the perfect state to modify for a different CPU. Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
HLA v1.100 is now available for FreeBSD
Hi All, I am pleased to announce that HLA v1.100 and the HLA standard library (v3.0) are now running natively under FreeBSD. For those who are unfamiliar with the product, HLA is a High Level Assembler for the 80x86. It allows you to write portable 80x86 code that runs under Windows, Linux, or FreeBSD with nothing more than a recompile. The product is available at the following URL http://webster.cs.ucr.edu/AsmTools/HLA/dnld.html HLA v1.100 is a major release of the HLA system. In addition to a few defect corrections, this release contains several major changes: 1) The system now ships, standard, with the HLA stdlib v3.0 library code. This new library is a big improvement over the v1.x stdlib code shipped with earlier (e.g., HLA v1.99) versions of the assembler. 2) HLA v1.100 (and the stdlib v3.0) now supports the FreeBSD operating system. Programs written for Windows and Linux can be ported to FreeBSD with nothing more than a recompile. 3) The standard example code has been modified to compile with, and use, the HLA stdlib v3.0. 4) The Art of Assembly examples have been modified to compile and run with the new stdlib (note that the frozen version of HLA, HLA v1.99, still provides links to the original AoA example code that uses stdlib v1.x, as shipped with HLA v1.99). 5) The stdlib documentation has been updated to reflect the use of the new library. -- -- HLA, the High-Level Assembler, is a powerful macro assembly language development system that runs under Windows, Linux, and FreeBSD operating systems. Carefully- written applications are portable between the operating systems with nothing more than a recompile of the source file. From a features point of view, HLA is one of the most powerful assemblers ever written. It's macro and compile-time language facilities far exceed those found in other assemblers. HLA was specifically designed to make learning and writing assembly language as easy as possible. HLA is fully supported by tons of documentation, example code, and other things that beginning and advanced programmers will find useful. The 32-bit edition of The Art of Assembly Language (No Starch Press) teaches introductory assembly language programming using HLA and is one of the most often-cited textbooks on the subject. You can read The Art of Assembly on-line at http://webster.cs.ucr.edu/AoA/ index.html. The HLA system also includes the HLA Standard Library, a collection of hundreds of ready to use library routines that simplify assembly language programming and provide (among other things) a usable interface to the underlying operating system. Full source code to the Standard Library is available. Most of the code of the HLA system is public domain and you may freely use that code as you please. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some FreeBSD performance Issues
Hello Randy, First, let me out myself as a fan of yours. It was your book that got me started on ASM and taught me a lot about computers and logic, plus it provided some entertainment and mental sustenance in pretty boring times, so thanks! Now, as for your problem: I think I have to agree with the others in this thread when they say that the problem likely isn't in FreeBSD. The following C program, which uses the read(2) call to read socket.h byte-by-byte, runs quickly (0.05 secs on my 2.1GHz system, measured with time(1)): code snipped This should be quite equivalent to your second and third code fragment; it does one read system call per byte, no buffering involved. This leads me to believe that the slowdown occurs in your fileio.read wrapper, or maybe in the process setup/teardown process. Actually, I'd already gone that route. Looking at the wrong copy of read.c (in the libstd directory) is what had me convinced of the buffering issue. However, the code you posted is still going through libc, so I'm not ready to trust that. However, I just used the syscall system call to make the same INT $80 calls from C that I'm making from the assembly code and that seems to work okay. I've disassembled the code for both programs (my assembly code and the C code that's making direct system calls) and for the life of me, I can't (yet) see any reason why the C code would run two orders of magnitude faster. I guess I'm going to have to look at the start-up code used by the C run-time system and see if it is doing something funny. Note to others: still haven't done ktrace, through looking at the object code for the two programs it's hard to believe that there would be extra system calls taking place or anything like that. If I had to guess at this point, I'd say that my calls are blocking a lot longer than the C program's. My user and system times are low, but real time is very high. Still haven't done ktrace. I'll try that when I get back into town later this week. Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some FreeBSD performance Issues
Hi All, Well, I've done some sleuthing and discovered some issues. First, the dd command produced approximately the same results everyone else was getting. So I rewrote a version of my test code in C using the stdlib read call and it had really great performance. Not understanding why C's code was so much faster, I dug into the source code and discovered that open/read/write/etc. use *buffered* I/O (which explains why dd performs so well). At this point I'm not sure why FreeBSD's API call is so slow (btw, it's not the system call that's responsible, if I make several additional API calls on each read, e.g., doing lseeks, this has only a marginal impact on performance). But it's pretty clear that if I expect reasonable performance in my own library I'm going to have to do the same thing that glib does and switch over to buffered I/O. Pain in the butt, but there's nothing else to do at this point. Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some FreeBSD performance Issues
You should also carefully do an strace or similar on Windows and Linux as well. You may find that you're doing a system call per byte on FreeBSD but not on those other systems. Certainly this might be possible under Windows, as I have no idea what happens once I link in one of the various kernel.dll modules. Under Linux, however, I am directly issuing the INT($80) instruction, so one system call per byte is being made. To answer a different question in the thread, I'm pretty sure I'm making only one FreeBSD call per byte, at least in one of the cases I posted. You'll note that one of the test examples made a call to bsd.read( fd, buffer, 1 );. That's just a function I wrote that rearranges parameters and sets up the stack, executes an INT( $80 ) instruction, cleans up the stack, and returns to the user. In a different test example I *was* making a couple of calls, (specifically to lseek to check to see if I'd reached EOF), but the performance difference was minimal (i.e., the time was being spent in the read call). I have to run off for an appt right now, but I'll try the dd command later today and see what that reports. I wonder if I'm only getting one character output per time slice, or something like that? Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Some FreeBSD performance Issues
Hi All, I recently ported my HLA (High Level Assembler) compiler to FreeBSD and, along with it, the HLA Standard Library. I have a performance-related question concerning file I/O. It appears that character-at-a-time file I/O is *exceptionally* slow. Yes, I realize that when processing large files I really ought to be doing block/buffered I/O to get the best performance, but for certain library routines I've written it's been far more convenient to do character-at-a-time I/O rather than deal with all the buffering issues. In the past, while slower, this character-at-a-time paradigm has provided reasonable, though not stellar, performance under Windows and Linux. However, with the port to FreeBSD I'm seeing a three-orders-of-magnitude performance loss. Here's my little test program: program t; #include( stdlib.hhf ) //#include( bsd.hhf ) static f :dword; buffer :char[64*1024]; begin t; fileio.open( socket.h, fileio.r ); mov( eax, f ); #if( false ) // Windows: 0.25 seconds // BSD: 5.2 seconds while( !fileio.eof( f )) do fileio.getc( f ); //stdout.put( (type char al )); endwhile; #elseif( false ) // Windows: 0.0 seconds (below 1ms threshold) // BSD: 5.2 seconds forever fileio.read( f, buffer, 1 ); breakif( eax 1 ); //stdout.putc( buffer[0] ); endfor; #elseif( false ) // BSD: 5.1 seconds forever bsd.read( f, buffer, 1 ); breakif( @c ); breakif( eax 1 ); //stdout.putc( buffer[0] ); endfor; #else // BSD: 0.016 seconds bsd.read( f, buffer, 64*1024 ); //stdout.write( buffer, eax ); #endif fileio.close( f ); end t; (I selectively set one of the conditionals to true to run a different test; yeah, this is HLA assembly code, but I suspect that most people who can read C can *mostly* figure out what's going on here). The fileio.open call is basically a bsd.open( socket.h, bsd.O_RDONLY ); API call. The socket.h file is about 19K long (it's from the FreeBSD include file set). In particular, I would draw your attention to the first two tests that do character-at-a-time I/O. The difference in performance between Windows and FreeBSD is dramatic (note: Linux numbers are comparable to Windows). Just to make sure that the library code wasn't doing something incredibly stupid, the third test makes a direct FreeBSD API call to read the data a byte at a time -- the results are comparable to the first two tests. Finally, I read the whole file at once, just to make sure the problem was character-at-a-time I/O (which obviously is the problem). Naturally, at one point I'd uncommented all the output statements to verify that I was reading the entire file -- no problem there. Is this really the performance I can expect from FreeBSD when doing character I/O this way? Is is there some tuning parameter I can set to change internal buffering or something? From this numbers, if I had to guess, I'd suspect that FreeBSD was re-reading the entire 4K (or whatever) block from the file cache everytime I read a single character. Can anyone explain what's going on here? I'm loathe to change my fileio module to add buffering as that will create some subtle semantic differences that could break existing code (I do have an object-oriented file I/O class that I'm going to use to implement buffered I/O, I would prefer to leave the fileio module unbuffered, if possible). And a more general question: if this is the way FreeBSD works, should something be done about it? Thanks, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getc in BSD (was FLEX issues)
-Original Message- From: Steve Kargl [EMAIL PROTECTED] Sent: Jul 4, 2006 11:40 AM To: Randall Hyde [EMAIL PROTECTED] Cc: freebsd-hackers@freebsd.org Subject: Re: getc in BSD (was FLEX issues) On Mon, Jul 03, 2006 at 11:34:41AM -0700, Randall Hyde wrote: The error reported is syntax error before numeric constant. This kind of gives me the impression that getc is defined a bit differently under FreeBSD than other environments? Any ideas? As others have stated, getc() is implemented via a macro, which may depend on other macros. In reading the flex NEWS file, I ran across the -Cr option. I added this option to your flex command, and the hla.flx file is processed and produces a compilable lex.yy.c. -- Steve Yeah, getc was the problem. I modified flex (via one the various macros it defines) to emit fgetc rather than getc and the problem went away. I'll have to try the -Cr option and see what happens there. Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
getc in BSD (was FLEX issues)
Well, having a little bit of time to play around with the issues I'm having with Flex under GCC, I've determined that the problem occurs in the following code fragment: for ( n = 0; n num_to_read ( c = getcError occurs on this line ( yyin ) ) != (EOF) 1 c != 'n'; ++n ) The error reported is syntax error before numeric constant. This kind of gives me the impression that getc is defined a bit differently under FreeBSD than other environments? Any ideas? Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: contiguous memory allocation problem
- Original Message -
From: Peter Jeremy [EMAIL PROTECTED]
To: Randall Hyde [EMAIL PROTECTED]
Sent: Saturday, July 01, 2006 11:10 PM
Subject: Re: FLEX, was Re: Return value of malloc(0)
The following compiles without error:
%{
typedef int YYSTYPE;
typedef int YYLTYPE;
/*
** Allow for a recursive version of Bison parser.
*/
#undef YY_DECL
#define YY_DECL int yylex( YYSTYPE *yylval, YYLTYPE *yylloc)
%}
%%
. ECHO;
%%
I'll accept that you are having a problem getting HLA to build. No-one
else is reporting problems. If you want assistance from other people
then you are going to need to help by either providing a test case to
reproduce the failure you are seeing or you are going to need to provide
the pre-processed context where the error occurs.
Uh, is the above *not* the test case you are asking for?
Does this particular code snippet compile for you? If so, then I've
definitely got some configuration problems with GCC on my machine.
BTW, if I haven't made myself clear, the problem with the code above is a
GCC error, not a FLEX error. That is, FLEX happily produces the yy.lex.c
output file, GCC under FreeBSD rejects the source code it produces. Yet that
*same exact* source code compiles just fine under Linux with GCC, Windows
with Borland C++, and Windows with VC++.
Creating a recursive lexer is a documented feature of FLEX. Indeed, I used
the example present in the FLEX documentation to pull this off. And I've
been using this code for about eight years on Windows and about four years
on Linux. Perhaps FreeBSD types have never tried to create a recursive
parser/lexer and haven't had to deal with this issue, but as you can see
from the code snippet above, this really has nothing to do with HLA, per se,
other than the fact that it uses a recursive lexer/parser.
And the fact remains, the code compiles just fine under Windows and Linux.
The compilation uses a documented feature of FLEX. There *is* a problem with
the implementation of GCC under FreeBSD (or header files under FreeBSD).
It's not specific to HLA. And I can't imagine how to give you a better test
case than the code above.
Cheers,
Randy Hyde
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FLEX, was Re: Return value of malloc(0)
-Original Message- How about feeding the C source through the preprocessor, stripping out the #line directives, compiling it and posting the exact gcc error and source context. Okay, I'll try that when I get home. But I was kind of under the impression that *GCC* runs the preprocessor on the input, during compilation :-). It may be a gcc bug, it may be a HLA bug or it could be an interaction between the FreeBSD headers and HLA. None of the code listed has *anything* to do with the HLA.FLX source (and certainly nothing to do with the rest of the HLA source code). It is quite possible that some FreeBSD headers conflict with this section of the FLEX output (remember, this is *canned* output code from FLEX, this is not generated in response to any FLEX input code). That's why my original question was so generic and not specific -- this would appear to be a generic problem with using FLEX output under BSD and I thought a quick question would affirm/deny that thought. Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FLEX, was Re: Return value of malloc(0)
-Original Message- From: Thomas David Rivers [EMAIL PROTECTED] Sent: Jun 29, 2006 3:17 AM To: freebsd-hackers@freebsd.org, [EMAIL PROTECTED] Subject: Re: FLEX, was Re: Return value of malloc(0) Randall Hyde [EMAIL PROTECTED] BTW, if anyone is intrested in the full FLEX source, it's part of the HLA (High Level Assembler) source package found here: http://webster.cs.ucr.edu/AsmTools/HLA/HLAv1.84/hlasrc.zip Just wondering if those guys knew that IBM calls their mainframe assembler the High Level Assembler, which they abbreviate HLASM. These guys would be just me, and I'm quite aware of HLASM. Of course, the term High Level Assembler predated IBM's HLASM by many years (indeed, the phrase was used a bit in the late 1960s, see Salomon's book for details). This isn't an x86 assembler like HLA - it's a z/Architecture (mainframe) assembler, very different beast indeed. Yes, their concept of High Level meant fancy macro facilities. Not back for a 1980's-era assembler. But - they may want to pick a new name, lest they incur the wrath of IBM's lawyers. I think IBM took that name in the 80s. Again, the generic term High Level Assembler predated HLASM, and HLA and HLASM are two different things. Further, there was an HLA for the Amiga some time back. Again, it's not like this term is terribly original. And I seriously doubt if IBM really cares at this point. Also - it seems that 'webster.cs.ucr.edu' has gone missing from DNS somehow; so I wasn't able to look at the source, although I was able to look at the web pages thanks to Yahoo's cache. Hmmm... Webster is a relatively famous site, so that's unusual. Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
Hi All, I'm trying to port my compiler from Linux to freeBSD. It looked like a simple job up to the point I ran my flex code through FLEX on freeBSD. When GCC processes lex.yy.c I get a complaint about an illegal numeric constant in yy_get_next_buffer, which is all FLEX generated (or prewritten) code. The thing compiler just fine under Linux. Any ideas? Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FLEX, was Re: Return value of malloc(0)
Without seeing the code or the actual error message, I'm guessing the answer is 42. Perhaps, some detail might be appropriate. I seriously doubt seeing the code will do much good. Here's the offending line: YY_INPUT( (yy_current_buffer-yy_ch_buf[number_to_move]), yy_n_chars, num_to_read ); This is from static int yy_get_next_buffer() Which is part of the canned code that comes with FLEX. Compiles just fine under Linux. Linux has a slightly newer version of GCC, but I've been compiling this code on Windows (Borland and VC++) as well as Linux for years without a problem (i.e., older versions of GCC). BTW, if anyone is intrested in the full FLEX source, it's part of the HLA (High Level Assembler) source package found here: http://webster.cs.ucr.edu/AsmTools/HLA/HLAv1.84/hlasrc.zip I compiled the FLEX code with the command line: flex -8 -i hla.flx This works fine, then I compile the GCC output with gcc -DfreeBSD -c -o lex.yy.o lex.yy.c and it stops with syntax error before numeric constant. As this code is in part of the FLEX-supplied C code, I would think that this problem would be independent of my particular flex code. BTW, I've tried using both the FLEX I use on Linux under BSD as well as the BSD-supplied version. I've even taken the FLEX output from freeBSD and compiled it under Linux (it compiles successfully. I'm using GCC 3.3.5 under Linux, 3.4.4 under BSD. Any known problems with 3.4.4 that would cause this? cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
